Veeam ONE: проблемы измерений, или С чего начать траблшутинг

За 3 года работа в технической поддержке можно увидеть многое. Как уже было раскрыто ранее, техподдержка в Veeam - это не просто call-центр, а высококвалифицированные инженеры уже на 1й линии поддержки, способные не только предоставить готовое решение или запросить логи, но и вместе с вами покопаться в базе данных, написать пару PowerShell скриптов для сопоставления различной информации полученной из инфраструктуры и, обернув все это в читаемо-понятную форму, выслать вам на электронный ящик. Накопив довольно обширный багаж знаний, хотелось бы поделиться опытом поддержки одного из наших продуктов - приложения для мониторинга виртуальных инфраструктур и серверов резервного копирования - Veeam ONE. Довольно часто (процентов 20 от общей нагрузки) нам приходится работать с кейсами относительно сбора данных производительности и их неверным отображением (интерпретацией) в продукте, в связи с чем и возникло желание немного пролить свет на данную тему. Лёгкий научпоп с оттенком технической документации.

В продолжение к статье моей коллеги Анастасии, хотелось бы поделиться опытом поддержки Veeam ONE, да и в целом немного рассказать о рабочих буднях инженера техподдержки в Veeam. Приятного чтения =)

После того как установка закончена, инфраструктура добавлена, и новые функции испробованы, можно расслабиться, откинуться на спинку кресла и начать получать удовольствие от жизни (мониторить). Для пущей наглядности, предлагаю продолжить в виде небольшого квеста: мы играем за Василия, Старшего инженера поддержки систем в компании на тысячу сотрудников. Инфраструктура небольшая: VMware-виртуализация с 5 хостами и парой десятков машин под критические сервисы, с репликацией, офсайт бэкапами, грамотными политиками хранения. В общем, наш герой не первый день в деле и свою работу знает, а также знает, что Veeam не создает снапшоты (это делает VMware после API-запроса со стороны нашего приложения), так что Василий уже не создает кейсы в поддержку каждый раз, когда видит подобное, а сначала консультируется с VMware-администратором.

Прочитав статью выше и приступив к мониторингу системы, наш герой замечает странную активность на графике производительности одного из хранилищ (disk write latency):

и довольно однозначную тревогу со стороны Veeam ONE monitor:

Естественно, первым делом Василий запустил пару тестов и проверил производительность с помощью сторонних приложений(SolarWinds, grafana), однако результаты были неоднозначными, и значения отличались в зависимости от программы.

Наш ход (можно выбрать только 1 вариант) :

1. Создать кейс в поддержку, проблема явно с Veeam ONE, ведь VMware не выдает никаких ошибок.

2. Провести больше тестов по измерению производительности.

3. Проверить значения счетчиков на стороне VMware.

4. Свой вариант, напишу в комментариях

Немного посовещавшись с коллегами, Василий решает, что не зря оплатил контракт на поддержку: https://www.veeam.com/licensing-pricing.html и создает запрос с неоднозначным заголовком: "Veeam ONE Monitor неправильно считает Latency для одного из хранилищ", указывая при этом Severity (уровень важности задачи) как 3: https://www.veeam.com/kb1771 , так как проблема не выглядит как критичная.

Опытный инженер Кристофер замечает новую задачу в CRM системе в 3 часа дня по тайскому времени (с забавными русскими символами), и решает проверить, что же случилось. Не найдя в ней никакой дополнительной информации, которая могла бы сократить время разбирательства, Кристофер решает запросить логи и скриншоты с ошибкой, которую видит клиент. Действие вполне стандартное и, более того, необходимое для того, чтобы начать расследование (понять версию продукта, количество объектов в инфраструктуре, выявить возможные "Known issues" и тд).

Вернемся к Василию. Тем временем наступил обед, наш герой не сразу заметил пришедшее письмо от поддержки и со спокойным сердцем ушел удовлетворять свои физиологические потребности. По возвращению в 14:10 по московскому времени его ждал набор задач, скопившихся за время обеда, писем в почтовом ящике было больше, 10 и Василий принялся отвечать на них сверху вниз, таким образом двигаясь от нового к старому. К моменту, когда настала очередь ответа из поддержки, было уже 3 часа дня. Прочитав письмо инженера, выглядящее как стандартная отписка, наш герой вздохнул от отчаяния, что никто вокруг не хочет работать, лишь бы запрашивать ненужные логи - и принялся писать ответ.

Наш ход (можно выбрать только 1 вариант):

1. Добрый день, Кристофер. Мне некогда заниматься вашими проблемами. Я целый день жду ответа. Пожалуйста, подключитесь удаленно и решите проблему как можно скорее.

2. Здравствуйте. Собрал логи, как вы и просили, но размер слишком большой, чтобы прикрепить к письму. Загрузил на SFTP сервер: https://www.veeam.com/kb1661 . Было бы удобно организовать звонок, чтобы обсудить детали как можно скорее.

3. Привет! Не могу собрать логи, могли бы мы организовать удаленную сессию, чтобы проверить вместе?

4. Свай вариант, напишу в комментарии.

Кристофер уже заканчивал свою смену, после тяжёлого трудового дня хотелось только одного - поскорее добавить все необходимые комментарии для своих задач от клиентов с Production support (так как они обслуживаются 24\7 и это необходимо для коллег, которые продолжат работу с кейсами), закрыть свой рабочий Macbook, и направиться на пляж, сесть на теплый песок, вдохнуть полную грудь слегка соленого воздуха и немного задержать, затем расслабиться, мягко выдохнуть и насладиться прекрасным закатом. Да, удаленная работа в Veeam сделала жизнь похожей на сказку.

Замечтавшись в предвкушении Кристофер на несколько секунд закрыл глаза перед монитором. Открыв их, он увидел уведомление, новое сообщение от клиента с Production support. В письме было сообщение от Василия с просьбой о удаленной сессии ...отправляет ссылку на Webex-сессию клиенту и набирает номер Василия. Что ж, Veeam, Compete to Win.

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

-Ало?

-Hello, my name is Cristopher, I am calling from Veeam Technical support regarding case # 00011122, may I speak to Vasiliy Bobrov?

Василий учил немецкий в школе, а в университете английский был только на первых 2 курсах в разряде общих дисциплин. Работа в IT, конечно, способствовала развитию навыка, и техническую документацию он вполне свободно читал, однако разговорная практика была только во время отпуска, поэтому на минуту он опешил. Но делать было нечего, напрягая мышцы лица и усердно потея от напряжения, Василий смог узнать номер сессии, подключился и договорился продолжить переписку в чате - с переводчиком будет попроще. “И почему они вообще предоставляют англоговорящих инженеров? Что за нонсенс! Мы же находимся в России! Эх, видимо футбол сегодня вечером придется смотреть в записи”, - подумал он.

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

-- Is it possible to open Vcenter Web console? - спросил Крис.

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

Крис вздохнул. Это будет долгая история, подумал он.

Спустя 10 минут интенсивной переписки и обзвона коллег Василий все-таки нашел способ подключиться к инфраструктуре. Доступ к хранилищу паролей был у их доменного администратора, таким образом, примерно без 20 минут 5 по Москве оба наших героя оказались там, где и следовало быть любому, столкнувшемуся с Performance Related Alarms для Vmware инфраструктуры - в веб консоли VMware.

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

Условно, все тревоги (Alarms) в Veeam ONE можно разделить на 2 типа: Событийные (event-related) и Состояний (state-related). О том, какая конкретно тревога активна, можно довольно просто узнать, нажав по ее имени в консоли Veeam ONE monitor:

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

К сожалению (или к счастью, смотря с какой стороны посмотреть), Техническая поддержка не имеет полномочий настраивать пользовательские системы. Однако, для этого есть специальная VASP-команда: https://www.veeam.com/find-a-veeam-accredited-service-partner.html, которая всегда будет рада помочь.

Открыв всплывающее меню напротив поля “Counter” (Счетчик), можно получить список доступных для Veeam ONE метрик, относящихся к типу правил, в нашем случае “Datastore performance”.

Там же можно выбрать другой тип правила (“Rule Type”):

Для каждого типа имеется свой набор настроек, которые можно персонально подстроить под инфраструктуру. Если интересно, напишите об этом в комментариях, на этот счет можно сделать отличную статью по типу Best Practices.

Возвращаясь к нашим героям: после аутентификации в консоли VMware Крис выбрал хранилище с ошибкой, отображенной в консоли Veeam. На вкладке Hosts выбрал один из серверов к которому подключено хранилище, открыл вкладку Monitor - Advanced - Chart Options, выбрал метрики, относящиеся к диску, и нашел в списке Write Latency

Указав необходимый промежуток времени из уведомления, Крис нажал кнопку Ок - и на экране возник график, довольно однозначно отображающий значения задержки на выбранном хранилище. Как и ожидалось, данные полностью совпадали с предупреждением и графиком в Veeam ONE, а все потому, что Veeam ONE не измеряет производительность. Как и в случае со снапшотами для задач резервного копирования, мы лишь собираем имеющиеся данные с инфраструктуры (через RestAPI для VMware и через WMI для Hyper-V). В определенных случаях данные могут собираться с нескольких мест и подсчитываться исходя из логики аларма (например, среднее значение скорости записи для всех объектов, использующих хранилище). Подробная информация о методе подсчета может быть предоставлена по запросу в технической поддержке. Также можно столкнуться с ситуацией, когда уведомление в Veeam ONE есть, а точки на графике нет. Такая ситуация может возникнуть из-за агрегации собранных значений. Существует 3 типа интервалов для стандартной модели и еще 3 для расширенной: https://www.veeam.com/kb2017:

Таким образом, нередки ситуации, когда тревога (Alarm) срабатывает на Real-time графике, однако на месячном, точки со значением выше пороговых из настроек тревоги не представлены, они попросту могут быть не учтены, если поведение было не постоянным, а пиковым. Помимо сбора и калькуляции данных для отображения на графике, в настройках тревоги есть отдельный пункт Aggregation. В зависимости от него тревога будет срабатывать по-разному. На пиковое значение, среднее, или минимальное - в зависимости от счетчика и метода агрегации - могут кардинально меняться условия срабатывания.

Василий вздохнул с облегчением, хоть он и не был администратором виртуальной инфраструктуры, однако график на экране довольно однозначно показывал, что информация в Veeam ONE ровно та же, что и со стороны Vmware, следовательно, и проблемы с Veeam, что в его зоне ответственности, здесь нет.

Крис подтвердил свои догадки и начал набирать длинное пояснительное сообщение в чате, разъясняя, что график в консоли Veeam ONE идентичен графику на стороне VMware, и о том, что проблем с системой измерения тут нет, описывая все до мельчайших подробностей, как положено Senior инженеру - и в этот момент увидел на экране сообщение. Сначала он даже немного поморгал, чтобы убедиться, что ему это не кажется, но уже через несколько секунд появилось всплывающее окно - "Василий вышел из чата". Сообщение выше было весьма лаконичным, но не менее значимым от этого: "thank you, I see it works".

Кристофер взглянул на часы после того как закончил с написанием комментариев и резюме по проведенному сеансу для пользователя (инженер не может закрыть кейс без подтверждения со стороны клиента, даже если во время сессии проблема была решена) и закрыл ноутбук. “Есть еще 15 минут на то, чтобы добраться до пляжа, - подумал он. - Как же круто, что 3 года назад я все таки попал в Veeam…”

Прощаясь с героями нашего короткого рассказа, хотелось бы подвести небольшой итог, своего рода резюме(привычка инженера поддержки). Что же можно вынести из статьи:

1. Veeam ONE не измеряет производительность напрямую. Информация о значениях сенсоров собирается с объектов(Хостов) виртуальной инфраструктуры, что позволяет избежать расхождений в данных между программой мониторинга и инфраструктурой.

2. Бывают ситуации, когда значения графиков производительности все же отличаются, но связано это не с проблемами измерений, а с различными методами агрегации. Если такое поведение было замечено - поддержка с радостью поможет вам с детальным описанием метода агрегации =)

3. Поддержка Veeam - довольно сильно отличается от провайдеров других услуг (по моему личному мнению, исходя из опыта работы как с B2B, так и B2C), в силу специфики сферы. На первой линии у нас работают технически квалифицированные инженеры, позволяя не разделять понятия, “Поддержка пользователей” и “Техническая поддержка”. При этом осуществляя поддержку 24/7. И как следствие, при обращении инженер запрашивает определенные технические данные(логи, скриншоты, детали инфраструктуры). Игнорировать их - собственноручно удлинять процесс решения проблемы.

4. Инженеры тоже люди. Мы стараемся, чтобы ваш опыт работы с нами был как можно более позитивным и заинтересованы в скорейшем решении возникшей ситуации не меньше, чем вы (KPI ни кто не отменял). Мы умеем не только устранить неисправность, но и поддержать беседу, посочувствовать, порадоваться вместе с вами! И нам, как и любому человеку, приятно когда нам отвечают взаимностью.

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

Хорошего вам дня и предстоящих выходных. Берегите себя!

С Уважением,

Veeam Technical support