Резервное копирование

Если инфошум о замедлении Твиттера вчера не позволил вам увидеть важное, то сообщаю. Вчера, 10 марта, произошел пожар в дата-центре провайдера OVH в Страсбурге, который входит в топ-5 крупнейших провайдеров. Полностью уничтожен центр обмена данными SBG2 (выгорел полностью) и на 30% ЦОД SBG1 (выгорело несколько боксов). Остальные 2 здания, находившиеся рядом, залиты водой.

Восстановление затопленных ЦОДов займет не менее 2 недель. В дата-центре размещались крупные европейские компании, часть из них уже заявили, что данные потеряны безвозвратно.

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

Я руковожу небольшимDigital-агентством, обслуживаем малый и средний бизнес, часто общаемся с начинающими предпринимателями. И постоянно сталкиваемся с анти-кейсами резервного копирования, возражениями вроде дорого, сложно, позже настроим, пока не надо и само рассосется.

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

1. Купите отдельные IP-адреса для боевых проектов

Если у вас облако, сервер или VPS, то один IP-адрес уже в комплекте. Если у вас виртуальный хостинг, то докупите к нему выделенный IP-адрес. В нештатных ситуациях это поможет быстро сменить хостинг или перенести проект на другой сервер. Обойдется примерно в99 руб. в месяц.

2. Используйте NS-сервера регистратора домена

Хостинг провайдеры предлагают перенести обслуживание DNS на свой хостинг. Не соглашайтесь, оставьте домен на NS-серверах регистратора домена, а в А-записи домена пропишите IP-адрес хостинга. Так вы сможете быстрее сменить хостинг в случае аварии. При изменении А-записи обновления распространятся в течение 1 часа, и ваш проект через час уже будет доступен на новом хостинге. Но если же вы будете менять NS-сервера, то обновления могу занять до 72 часов. Обычно регистраторы предоставляют услугубесплатно, но RU-center хочет денег.

3. Включите локальное резервное копирование на хостинге

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

4. Храните 1-3 локальных бэкапа

Как правило, дисковое пространство на хостинге стоит не дешево, даже если вы покупаете отдельный диск для бэкапов. Поэтому нецелесообразно хранить там большие объёмы информации. Храните только самые последнии копии за предыдущие дни.

5. Настройте резервное копирование на отдельный сервер

Я рекомендую использовать облака как основное хранилище резервных копий, но вы можете использовать и простой сервер или дешевый хостинг от другого провайдера. Главное, чтобы сервера этого другого провайдера располагались не в том же дата-центре, что и основной сайт. Но облака гораздо дешевле, хранение одного терабайта там стоит обычнооколо 500 руб. в месяц. Можно использовать Google Cloud, AWS или Yandex Cloud для них есть готовые инструменты резервного копирования, поэтому их легко настроить. Обычно рекомендуют хранить 7 копий за неделю, 4 копии за месяц, 12 копий за год так и сделайте.

6. Поверяйте бэкапы раз в неделю

Минимум раз в неделю проверяйте факт создания бэкапов и их размер. Любой сбой может нарушить вашу схему резервного копирования: смена пароля, обновление ПО, переполнение диска, нехватка денег на счету. Потратьте всего 2-3 минуты в неделю этого хватит, чтобы предотвратить неприятности.

7. Восстанавливайте бэкапы раз в месяц

Хотя бы изредка восстанавливайте свои резервные копии на тестовом сервере. Идеально делать это раз в месяц, минимум хотя бы раз в 3 месяца. Одно дело иметь резервные копии, и совсем другое иметь реально работающие резервные копии. Вы должны быть уверены, что в нужный момент бэкапы вам реально помогут и у вас есть возможность их быстро развернуть. Удобно и дешево можно разворачивать облачные сервера на reg.ru или hetzner.cloud, потратитемаксимум 100-200 руб за раз. Процедура займет всего 1-2 часа, но убережет от проблем в будущем.

Вот и все, просто соблюдайте хотя бы эти простые правила.

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

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

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

2 апреля 2021 года закончилось ежегодное мероприятие Cyber Protection Week, которая раньше называлась BackUp Day. За последние годы пришлось уйти от формата одного дня, потому что тем для обсуждения стало очень много, и вести разговор не только о бэкапе, но и о других аспектах киберзащиты. Сегодня мы делимся основными выводами, которые были сделаны по итогам Cyber Protection Week 2021 с учетом исследований и опросов участников мероприятия.

В этому году в рамкахCyber Protection Week был проведен опрос 2200 пользователей из 22 разных стран на 6 континентах, и в этом посте мы хотим поделиться его результатами. Помимо традиционных вопросов мы хотели узнать, как на людей повлияли события прошлого года пандемия COVID, введенные в разных странах локдауны и ограничения. В прошлом мы уже писали о том, что сами тема коронавируса создала повод для множества манипуляций и кибератак. Но было интересно узнать, как сами пользователи оценивают динамику угроз, с которыми им пришлось столкнуться в реальности. Ведь во время самоизоляции зависимость от сохранности данных и цифровых сервисовзначительно возросла.

1.Потерь данных становится все больше, а уровень защиты падает

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

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

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

2. Пользователи оказались не в курсе большинства угроз

При том, что за время пандемии количество кибератак выросло на 400%, исследование показало, что почти 25% частных пользователей вообще не слышали о программах-вымогателях, крпито-джекинге, DoS / DDoS атаках или взломах интернета вещей. Для читателей Хабра это может показаться странным, но значительная часть обычных пользователей вообще не в курсе, что может произойти с их данными. И эти результаты исследования Cyber Protection Week Report напрямую коррелируют с объемами потери данных частными пользователями.

Почти 40% частных пользователей отметили, что они даже не поняли бы, если бы к их данным кто-то получил доступ или изменил их. Этот показатель вырос на 10% по сравнению с результатами Cyber Protection Week 2020 года. Еще больше людей (43%) не знают, может ли установленное защитное ПО противодействовать атакам нулевого дня. И это серьезная проблема, ведь с учетом использования искусственного интеллекта и готовых конструкторов, специалисты каждый день обнаруживают350 000 новых разновидностей вредоносного ПО. Получается, чтьо каждый подобный экземпляр может скомпрометировать данные плохо защищенных пользователей.

3.Безопасность обычных пользователей чаще всего зависит от автоматических процедур

Да, сегодня многие пользователи совершают определенные действия, чтобы защитить свою приватность в сети. Однако эти шаги, как правило, не выходят за рамки базовых процедур, которые применяются автоматически или даже принудительно. Например, люди устанавливают более сложные пароли, потому что без них нельзя зарегистрироваться, включают защиту сетей Wi-Fi и многофакторную аутентификацию в приложениях, если им настоятельно рекомендовали это сделать.

И хотя мы наблюдаем 20% рост количества пользователей, применяющих облачный бэкап, по сравнению с прошлым годом, в основном это происходит потому, что многие цифровые сервисы стали выполнять его автоматически. Увы, пользователи редко выходят за пределы этих базовых шагов, потому что для более тонкой защиты необходимо совершать проактивные действия и быть в курсе как самих угроз, так и того урона, который они могут нанести.

Заключение

Растущий спектр угроз одновременно с низкой осведомленностью пользователей, не слишком глубоко погружающихся в ИТ, создает прекрасные условия для новых атак и манипуляций с данными. Учитывая неутешительную статистику, вредоносное ПО все чаще находит способ попасть на компьютер жертвы, так что мы рекомендуем помочь своим друзьям и родственникам нормально настроить киберзащиту, чтобы они не стали очередными жертвами киберпреступников.

Администраторы кластеров kubernetes сталкиваются с задачей сохранить конфигурацию ресурсов из пространства имен и перенести в другой кластер, или же сделать резервную копию нестабильной тестовой площадки. С этой задачей без проблем справляется бегло написанный в терминале односторчный скрипт с утилитой kubectl, но что если надоело каждый раз тратить пару минут времени на очередное написание скрипта. Так и появилась утилита kube-dump, по сути это утилита которая умеет только одно - дампить ресурсы кластера.

При помощи данной утилиты вы можете сохранить ресурсы кластера в виде чистого yaml манифеста без лишних метаданных.

Ключевые особенности:

• Сохранение выполняется только для тех ресурсов, к которым у вас есть доступ на чтение.

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

• К сохранению подлежат как ресурсы пространств имен, так и глобальные ресурсы кластера.

• Использовать утилиту можно локально как обычный скрипт или запустить в контейнере или в кластере kubernetes к примеру как CronJob.

• Может создавать архивы и ротировать их за собой.

• Может фиксировать состояние в git репозитории и отправлять в удаленный репозиторий.

• Вы можете указать конкретный перечень ресурсов кластера для выгрузки.

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

Начало работы

Необходимый минимум для запуска это наличие установленного kubectl и подключенного в него кластера, а также утилит jq и yq. Более подробно описано на странице документации по локальному запуску, а аргументы командной строки описаны здесь или же доступны по ключу --help.

Запустим утилиту для сохранения всех ресурсов кластера:

./kube-dump dump

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

Получим свежий образ и запустим утилиту для сохранения пространств имен dev и prod в смонтированную директорию /dump, где для доступа к кластеру мы пробрасываем в контейнер свой конфигурационный файл от kubectl.

docker pull woozymasta/kube-dump:latestdocker run --tty --interactive --rm \  --volume $HOME/.kube:/.kube \  --volume $HOME/dump:/dump \  woozymasta/kube-dump:latest \  dump-namespaces -n dev,prod -d /dump --kube-config /.kube/config

Установка CronJob в кластер

Рассмотрим более сложный пример когда контейнер будет запущен в кластере как CronJob который будет каждую ночь снимать дамп ресурсов и фиксировать правки в git репозитории с последующей отправкой в удаленный репозиторий. Пример подробно описан в статье.

В данном примере подразумевается что у вас есть доступ к управлению ролями кластера, потому что мы будем использовать для работы ServiceAccount и стандартную роль view. Если же вам не подходит глобальная роль view, вы можете создать свою роль для пространства имен или кластера, в помощь можете взять этот пример.

Создадим пространство имен где будет работать наш CronJob и ServiceAccount который будет использовать ClusterRoleBinding для роли view:

kubectl create ns kube-dumpkubectl -n kube-dump apply -f \  https://raw.githubusercontent.com/WoozyMasta/kube-dump/master/deploy/cluster-role-view.yaml

В качестве примера будем использовать авторизацию в GitLab по OAuth токену, по этому создадим секрет с адресом репозитория и токеном для авторизации:\

kubectl -n kube-dump create secret generic kube-dump \  --from-literal=GIT_REMOTE_URL=https://oauth2:$TOKEN@corp-gitlab.com/devops/cluster-bkp.git

Перед установкой настройте переменные окружения под ваши нужды, в примере по умолчанию установлен режим копирования пространств имен dev и prod с последующей фиксацией изменений в ветке my-cluster и отправкой в удаленный репозиторий.

Настроим CronJob в которм укажем периодичность запуска задания:

spec:  schedule: "0 1 * * *"

Или же установите пример как есть и после отредактируйте его:

kubectl -n kube-dump apply -f \  https://github.com/WoozyMasta/kube-dump/blob/master/deploy/cronjob-git-token.yamlkubectl -n kube-dump edit cronjobs.batch kube-dump

Планы по дальнейшему развитию

• Реализовать отправку дампов в s3 совместимое хранилище;

• Отправка уведомлений по электронной почте и через веб-хук;

• Git-crypt для шифрования чувствительных данных;

• Автодополнение в Bash/Zsh;

• Поддержка OpenShift.

Также буду рад Вашим комментариям и предложениям с идеями и критикой.

Ссылки

• GitHub

• Docker Hub

• GitHub pages

Уже, наверное, только ленивый не повторил десять раз, что ковид послужил катализатором взрывного роста как самих облаков, так и разного рода облачных сервисов. Словом, всё, что как-то относится к облачной теме, стало резко расти и увеличиваться в объёмах. Причина банальная: всех разогнали по домам, и для многих возросшие нагрузки на их сервисы послужили тем самым громом, после которого надо перекреститься и начинать уже что-то делать. Вот все и начали срочно мигрировать. У кого-то процесс перехода прошёл гладко, у кого-то не очень, однако все мы как-то научились жить в новой реальности и теперь, когда вау-эффект прошёл, многие компании стали переключаться с чисто инфраструктурных вопросов на вопрос сохранности данных. Когда твои сервера у тебя под боком, ты сам себе хозяин и молодец. А что делать, когда твои продукты крутятся не пойми где? Довериться надежности облака? Бекапить облачные сервисы другими сервисами этого же облака? Бекапить из облака на землю? Бекапить одного облако в другое? Вопрос важный, ответ не ясен, давайте разбираться.

Для начала повторим банальное, но важное утверждение: облака - не серебряная пуля и не ответ на главный вопрос жизни, Вселенной и всего такого. Облако - это просто элемент инфраструктуры, который позволяет вам решать возникшие у вас задачи. И если сами облака работают уже достаточно стабильно и предсказуемо, то на идеологическом уровне всё ещё имеются проблемы. И основная заключена в том, что, начав использовать облако, вы получаете как бы две инфраструктуры: классическую и облачную. То есть каждая управляется своими инструментами и из разных мест, хотя всё IT сообщество последние годы стремится исключительно к унификации. Значит облако должно быть не обособленным куском инфраструктуры, а просто одной из её частей и не требовать к себе внимания больше, чем все остальные.

Лет 10-12 назад все боялись виртуализации и смотрели на неё исключительно как на диковинку заморскую. А знаете, какими были первые внедрения виртуальных машин? Исключительно в качестве DR (disaster recovery) площадок. То есть технология новая, чего от неё ждать - непонятно, и перевозить туда продакшн боязно. Поэтому мы её пока будем изучать в лабораторных условиях, а на случай аварии пусть стоит в углу готовая к бою копия инфраструктуры. Потом могла или авария случиться, или просто IT отдел набирался смелости и начинал мигрировать часть сервисов. Причины тут не важны, тут интересны последствия: после миграции на виртуалки всё продолжало работать не хуже, чем до этого. Только вот оперировать этим становилось на порядок удобнее. Затем неизбежно вставал вопрос: Ок, виртуализация - это здорово и удобно, но как нам переехать обратно?. А обратно было уже не переехать. Во всяком случае не настолько просто, как при переходе на виртуалки. Да и сами люди уже не хотели возвращаться к старой модели, ибо новая на практике доказала свою эффективность и удобство.

И с облаками (особенно IaaS) сейчас происходит ровно тот же сценарий: мы их боимся > давайте потестируем и организуем облачную DR площадку > частично перевозим прод > оказывается, оно работает и это удобно > обратно вернуться сложно, да и не очень хочется, если честно. Всё это и привело к взрывному росту популярности. Даже в самой далёкой от IT компании если сейчас поднять вопрос о модной нынче цифровой трансформации, мало кто захочет заниматься закупками железа, планированием его размещения и ждать поставки полгода, если задачу можно решить созданием нескольких учёток в AWS/Azure, сидя дома на диване. Плюс многие компании сейчас воочию убедились в необходимости иметь под рукой возможность быстро масштабироваться в любую сторону. И быстрого - это значит здесь и сейчас, а не зависеть от поставщиков и прочих непредсказуемых факторов.

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

Когда у нас был железный сервер, с ним всё было просто и понятно. Когда он превратился в виртуальную машину, сначала было непонятно, но со временем появились приложения для бекапа виртуальных машин - и вот они бекапятся так же, как и обычные сервера.Теперь машина переехала в облако, и в первый момент у нас основной вопрос - не куда её бекапить, а как вообще её бекапить?

Первое, что приходит в голову - это сделать бекап машины изнутри, как было заведено ещё со времён больших железных серверов. Решение хорошее, но крайне далёкое от оптимального. Ведь в случае аварии у нас будет образ, для разворачивания которого надо первоначально развернуть машину, не ошибиться с её конфигурацией и надеяться, что со стороны облака не было изменений, из-за которых гостевая ОС не захочет стартовать на новой машине. Потом туда надо залить бекап и развернуть его. И хорошо бы по пути не разориться на платежах за трафик, IO и прочее. Как вариант, мы можем делать бекап только приложений, забирая дамп условной базы данных, но тут мы обрекаем себя на ещё большее количество увлекательных приключений при восстановлении. Да и интеграция всего этого в существующие процессы резервного копирования априори выглядит как нагромождение костылей.

Второй приходящий в голову сценарий - это посмотреть в сторону предлагаемых самим облаком решений. Тут есть два варианта развития событий. В первом варианте облачный провайдер строит своё облако на публичном коробочном решении - VMware Cloud, например. Плюс этого подхода в том, что для таких решений давно есть соответствующие продукты, которые будут работать с предсказуемым результатом. Тот же VMware Cloud - отличный пример таких интеграций, так как есть огромное количество клауд-провайдеров, где прямо заявляется о наличии услуги бекапов машин с помощью Veeam. В результате мы получаем знакомое решение, с понятным результатом и возможностями по интеграции. Звучит неплохо.

Другой вариант - это когда провайдер делает своё облако на закрытом решении. Причём отнесём сюда не только AWS, Azure и т.д., но и провайдеров, построивших своё облако на решениях, требующих тщательной доработки напильником под свои нужды, вроде OpenStack. Обычно такие провайдеры предлагают некие встроенные решения, однако при ближайшем рассмотрении они зачастую очень бедны по своему функционалу и накладывают массу ограничений на бекапируемые машины. Даже если посмотреть на AWS, то предлагаемое ими решение не будет претендовать на звание хотя бы хорошего из-за имеющихся ограничений. Например, бекапы автоматически складываются на S3 с последующим переездом в Glacier, без альтернативных путей. Здорово, конечно, но что делать если этот вариант не подходит? А что в это время будет происходить с приложениями внутри виртуалки и насколько они хорошо будут себя чувствовать после рестора? Тут вся проблема в том, что Amazon предлагает именно законченное решение, а не технический инструмент для выстраивания необходимого сервиса. Причина такого поведения проста: сделать и поддерживать гибкий инструмент в разы сложнее, чем законченное решение с парой опций, которое охватит потребности вероятного большинства клиентов. Профильная задача облачного провайдера - это поддержание функционирования облака, а всё остальное идёт по остаточному принципу. Так что инструмент для галочки есть, но решать свои задачи до конца мы им не можем. А про интеграцию с существующими решениями даже заикаться не будем. Её нет и не предвидится.

Так что в этом месте на сцену выскакивают 3rd party решения, использующие предоставляемые облаками API и старающиеся реализовать максимум гибкости в имеющихся условиях. Вроде наших Veeam Backup for Microsoft Azure, for AWS и прочих Office 365. Все они построены на стандартных API, однако позволяют реализовать логику резервного копирования, схожую с той, к которой вы привыкли до облаков, и, что самое важное: прозрачно интегрировать эти процессы в существующую инфраструктуру. Да, там есть свои чисто технические ограничения из-за предоставляемых вендором возможностей, однако с каждым релизом список доступных функций становится всё больше и больше.

И это чистая правда: если верить отзывам клиентов, то возможность интеграции облачных бекапов в общий пайплайн (назовём это так) вашего резервного копирования - это именно то, чего им так недостаёт в наше увлекательное облачное время. То есть раньше у нас весь выбор действий был ограничен возможностью бекапить машину из AWS в S3. И туда же её и восстановить. Получается классическое standalone-решение на минималках. А теперь рассмотрим облачный бекап в качестве равноценного участника всей инфраструктуры. Первым делом хочется скачать бекап из облака и положить его рядом с остальными. Причём скачать не просто в виде набора файлов, а чтобы наше бекапное приложение сохранило возможность полноценного оперирования им. Да, AWS даёт нам околобесплатный Glacier для долгосрочного хранения, однако ждать до нескольких дней для восстановления данных - это даже не смешно. Конечно, несколько дней - это максимальный срок, указанный в договоре, и скорее всего данные будут доступны раньше, но кто захочет добровольно попасть в то меньшинство, которое не скорее всего?

Но это пока не самое интересное. Как все мы понимаем, бекапы делаются не ради бекапов, а ради возможности восстановления. И будет странно ожидать от облачного провайдера возможности восстановить его виртуалки в вашу наземную инфраструктуру или, случись что, в другое облако. Однако мы эту возможность даём и позволяем восстанавливать ваши рабочие данные хоть в виде виртуалки в гипервизоре, хоть на обычный железный сервер, хоть перегонять машины из AWS в Azure. Про банальное желание восстановить отдельные файлы из машины или отдельные элементы приложений даже говорить не буду, так как это само собой разумеющийся функционал.

Следующий неочевидный нюанс: контроль расходов. Насколько точно вы сможете спрогнозировать размер счёта за создание и хранение бекапа на S3? Да, записать туда данные будет ничего не стоить, но каждая операция верификации записанных данных уже будет стоить денег. А что с созданием инкрементов, когда данные дописываются с оглядкой на уже хранящиеся (да-да, это снова масса платных операций чтения)? А сколько будет стоить удалить устаревшие точки? Словом, курочка по зёрнышку - и в конце месяца за казавшийся недорогим S3 вам может прийти крайне неприятный счёт. Поэтому при работе с облачными данными надо стараться чётко понимать, сколько будет стоить каждое ваше телодвижение и как можно сохранить максимальное количество денег. Мы в Veeam настолько преисполнились это темой, что разработали собственный калькулятор, позволяющий довольно неплохо предсказывать стоимость хранения ваших бекапов. Да, подобный сервис можно и самому организовать через калькулятор AWS, однако давайте прикинем, сколько надо учесть переменных: стоимость EBS снапшотов, стоимость самого S3 хранилища, стоимость работы воркера (машины, которая занимается созданием бекапов), не забываем про потребление трафика на случай использования разных регионов или желания скачать бекап, и помним про стоимость всех операций внутри S3. Так что не самое очевидное уравнение получается.

Исходя из всего сказанного выше, напрашивается очевидный вывод: сейчас уже не надо искать ответ на вопрос Как мне бекапить данные в облаке. Он давно решён, и на рынке есть решения на любой вкус. Однако на чём сейчас стоит сосредоточить своё внимание, так это на поиске ответа на вопрос Как мне сделать платформу для резервного копирования, чтобы я из единой консоли мог бекапить и восстанавливать свои данные независимо от того, где они находятся и куда мне хочется их восстановить?. Это и позволит вам рассматривать облако как полноценного участника вашей инфраструктуры, а не в виде обособленного ее элемента.

Помните, как во второй половине 90-х один известный тогда профессор хрипло пел Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.

И да, в посте будет математика. Целых две формулы. Я предупредил.

Как и любое другое здравое современное приложение, Veeam Backup & Replication спроектирован таким образом, чтобы минимально загружать своему пользователю мозги и максимально эффективно справляться с поставленной задачей. На местах этот высокопарный посыл выражается в том, что независимо от масштаба вашей задачи устанавливается Veeam в три клика, ещё в пять делается первичная настройка и всё, полетели бекапы бекапироваться. Но как все мы отлично понимаем, это всего лишь радужная теория из мира с поняшками и бабочками. Ведь даже если самому приложению совершенно без разницы, бекапить ли ваш ноутбук на подключенный usb диск или гонять сотни терабайт снапшотов по FC фабрике (а ему действительно всё равно), то происходить это всё будет на вполне конкретном физическом железе, которому предстоит обработать все эти потоки данных. То есть, в то время, пока софтовая часть остаётся неизменной, архитектура решения в целом меняется до неузнаваемости.

Если скорость бекапа своего компа можно легко увеличить на порядок простой заменой USB 2.0 диска на USB 3.1, то имея задачу забекапить развесистую ферму серверов, да ещё и раскиданную по всему миру, можно столкнуться с тем, что в одном месте окажется слабый CPU, в другом процесс утыкается в объёмы доступной RAM, в третьем все ждут, когда контроллер дисковой полки соизволит записать очередную порцию данных, а в четвёртом так и вообще еле живой линк с внешним миром. Так что чем сложнее задача, тем проще и обиднее будет ошибиться с выбором любого из компонентов системы. И если за покупку слишком мощных серверов ругать вас не будут, то промашка в меньшую сторону скорее всего чревата большим числом неприятных разговоров в самом ближайшем будущем. Здесь - ты не поместился в бекапное окно, здесь - попытка сделать снепшот приводит к развалу кластера, а вот там просто нет ресурсов и придётся просить докупить новых железок. Так что тема планирования потребления CPU и RAM для бекапов не настолько и третьесортная задача, как к ней многие относятся.

Но прежде чем начать выписывать себе бюджеты на сотни CPU и тысячи гигабайт RAM, давайте освежим в памяти общую архитектуру Veeam Backup & Replication, чтобы точно не путаться в определениях и назначении компонентов.

1. Сам VBR (Veeam Backup & Replication) сервер. Командный центр, оркестратор, ЦУП, разум улья, словом, называйте как хотите, но основная его роль - это синхронизация всех остальных компонентов и выдача команд на запуск разных увлекательных внутренних процессов, отслеживание расписания, и так далее. Технически ничего не мешает разместить вообще все компоненты на одной машине, и они даже будут работать. Однако такой сервер и ресурсов потребует соответствующих, и производительность его будет далека от совершенства. Так что лучше размещать всё остальное согласно назначению. Об этом ниже.

2. База данных. Veeam - это классическое приложение, хранящее всю важную информацию в базе данных. Где и как вы расположите эту базу данных - его совершенно не волнует. Лишь бы до неё была связь и сервер стабильно работал. Хотите на одной машине с основной консолью? Пожалуйста! Для этого в установщике лежит Microsoft SQL Server 2016 SP2 Express Edition, который будет автоматически развёрнут и настроен самым лучшим образом. У вас уже есть своя инсталляция и вы хотите, чтобы база крутилась там? Без проблем! Просто укажите установщику адрес сервера и с какой учёткой туда идти. В процессе эксплуатации передумали и хотите перенести базу на другой сервер? Просто измените ключик в реестре или воспользуйтесь встроенной тулой. Всё для вас.

3. Прокси сервер или просто прокся. Не знаю, почему когда-то давно было решено назвать их именно так, но точно знаю, что новичков это название иногда путает (именно путает, а не пугает). Но не будем искать виноватых, а просто зафиксируем, что прокси - это тот компонент инфраструктуры, который будет читать данные с бекапируемого объёкта и укладывать их в бекап. Это если упрощенно, потому что на самом деле данные будут сжиматься, дедуплицироваться, шифроваться, на их пути могут возникнуть другие прокси, нестабильные каналы связи и всякие хитрые хранилища. Не суть. Сейчас важно зафиксировать, что прокси - это то, что примет на себя основной удар по обработке данных. Они запускают пары data movers, один из которых что-то откуда-то читает, а второй что-то куда-то пишет. Чуете очевидную мораль? Чем ближе ваша прокся к бекапируемому объекту и чем ближе к ней хранилище бекапов, тем быстрее будет идти процесс. Но тут важно не увлекаться и помнить, что чудес не бывает. Ваши машины лежат на FC сторадже? Так будьте любезны и проксе предоставить FC подключение, иначе как ей данные получать? Ну не через managed интерфейс хоста же, ну честное слово. Хотя на самом деле с этой проблемой связана одна из самых частых ошибок при конфигурации - пользователь хочет, чтобы бекапы работали через Virtual Appliance, а работает через Network. Но не будем сейчас о грустном.

4. Репозиторий. Он же бекапный сторадж. Может быть буквально чем угодно, к чему можно присоединиться, а ещё лучше, если там можно запустить наш дата мувер. Запустились на целевой системе - значит, можем контролировать процесс и часть операций проводить локально. Не можем запуститься на целевой системе - значит, приходится верить на слово, а каждый байт информации гонять взад-назад по сети. Так что во время любого синтетического трансформа бекапа, лежащего на сетевой шаре, ваша сеть будет вас ненавидеть. Поэтому Windows/Linux сервер - это твой бро, сетевые шары нет. Работать, конечно, будет, но медленно и не пойми как. Есть ещё целая россыпь вариантов вроде S3, дедуплицирующих систем и всяких специфических файловых систем вроде XFS, но это тема отдельного разговора. Просто помним, что репозиторий - это наше хранилище и гарант безопасного сна. Ну и особенно хорошо, если там можно запускать дата муверы.

5. Enterprise Manager. Командир над командирами, в котором можно объединить управление несколькими VBR серверами и дать рядовым пользователям пользоваться частью функций через простенький веб-интерфейс. Например, можно выдать гранулярные права своему хелпдеску на восстановление определённых объектов на определённых машинах. Удалил пользователь письмо и корзину почистил, а хелпдеск ему хлоп - и вытаскивает это письмо из бекапа. Красота.

6. И цифрой шесть давайте обозначим всё остальное, включая комбо-сервера, на которых крутится сразу по несколько ролей. Например, использовать один сервер в качестве и прокси, и репозитория - вполне нормальная идея, если серверу хватает ресурсов. Ну и помимо основных компонентов есть ещё целая россыпь вспомогательных: tape server, wan accelerator, cache repository и прочие gateway servers. Тут можно долго всё перечислять, тщательно объясняя, кто и зачем нужен, но мы здесь не за этим собрались. Лучше почитайте документацию, благо там всё очень понятно и подробно описано.

Главный посыл всего вышесказанного: VBR- это не одна конкретная машина, на которой вы прокликали мастер установки и получили работающее решение. Вернее, в небольших инсталляциях это, может, и так, но если у вас раскидистая инфраструктура, то VBR полностью готов ей соответствовать. Все эти компоненты и созданы, дабы дать возможность масштабироваться в зависимости от решаемой задачи. Странно будет поставить все компоненты VBR в европейском датацентре, если предстоит бекапить виртуалки по всему миру. Оставьте у себя в офисе управляющий сервер, а прокси и репозитории расположите рядом с машинами. Всё для вашего удобства.

С этим разобрались. Что дальше? Обычно всем сразу на ум приходит идея посчитать количество необходимого для хранения бекапов дискового пространства. Для этого принимается стратегическое решение: бекапить каждую машину раз в день и прикинуть, сколько же нам надо терабайт под бекапы - с помощью отличного калькулятора от Тимоти Девина.

Идея, конечно, хорошая, но вот реализация так себе. Давайте всё же сделаем это несколько грамотней и получим сразу все вводные, необходимые для наших расчётов. И да, сейчас будет очередной чеклист:

1. Первым шагом будет проработка ваших RPO и RTO метрик, про которые уже было сказано очень много раз. Главное - запомнить основной посыл: не вы должны решать, с какой периодичностью делать бекапы и как быстро они должны восстанавливаться, а владельцы сервисов и те, кто называется на западе applications team. Вам надо собраться всех вместе и решить, для какого сервиса какой простой будет допустим и какой объём потерянных данных вы сможете пережить без того, что вас всех уволят, а компания закроется. Исходя из этого вы уже сможете построить вашу схему ротации бекапов, известную в англоязычной литературе как retention scheme.

2. После этого мы уже можем переходить к подсчётам необходимого места. И здесь не надо пытаться изобрести колесо: просто возьмите и посчитайте, сколько места сейчас занимает ваш продакшн.Да, реальный размер будет меньше за счёт дедупликации, компрессии и отбрасывания ненужных блоков, но это тот самый случай, когда никто вам не скажет как именно посчитать коэффициент сжатия (кроме эффективных маркетологов и продавцов). А запас, как мы знаем, карман не тянет.

3. Посчитали свои терабайты? Отлично, теперь считаем, сколько у нас виртуальных машин/серверов. Совсем хорошо будет, если получится посчитать количество дисков на них, так как несколько дисков параллельно обрабатывать можно, а вот один в несколько потоков не получится. Соответственно, два диска по 500Гб забекапятся быстрее, чем один на терабайт, при прочих равных.

4. Размер окна резервного копирования ака Backup window. Время, за которое должен состояться ваше бекап. Тут не всё так просто, как может показаться. Есть непосредственно бекап продакшена, который должен быть совершён вне времени основной офисной активности, чтобы не повлиять на сервисы. А есть некие побочные вещи, вроде бекап копи, синтетических трансформаций, записи бекапов на ленты и так далее. Если ваша инфраструктура резервного копирования находится на отдельном оборудовании и может спокойно заниматься своими делами, то вам повезло. Если нет, то ваша задача усложняется: надо, чтобы и сам бекап успел сделаться, и все последующие операции.

5. И завершает наш парад вводных самая спорная метрика: сколько новых данных в день будет появляться на ваших серверах. Daily change rate, как называют на западе. К сожалению, тут нет единственно верного ответа, как посчитать этот параметр. Кто-то ограничивается примерными значениями, кто-то делает снапшоты и через сутки смотрит на их размеры. Вариантов много, и точного на сто процентов нет. Но вполне можно обойтись и средней температурой по больнице: для машин без высокой активности считается, что в день изменяется не более 5% диска, а в среднем по больнице принято считать, что 10% изменяющихся данных в день - это отличный показатель для дальнейших расчётов.

У пунктов 2 и 5 есть тонкий момент. Как вы прекрасно понимаете, требуемые мощности для того, чтобы успешно и вовремя забекапить весь прод, несколько отличаются от мощностей, необходимых для создания инкрементов. Иногда на порядок. То есть покупать супер-мощный сервер под прокси, который будет только раз в год (а вдруг вам достаточно) упаковывать все ваши петабайты за ночь, а все оставшиеся дни просто греть воздух, может статься и не очень разумным. Возможно, проще будет купить сервер в два раза меньше, но выделять под бекап не четыре часа, а восемь. Или вообще разбить процесс на несколько дней, делая полный бекап только части машин. Словом, момент тонкий и требует отдельного осмысления.

Зато теперь, когда у нас наконец-то есть все вводные данные, можно смело вооружаться калькулятором и начинать считать. При подсчётах мы будем исходить из того, что следуем рекомендациям VBR, и количество параллельно обрабатываемых тасок равно количеству имеющихся у процессора ядер. А одна таска - это один обрабатываемый диск. То есть если у нас на прокси CPU с четырьмя ядрами, то одновременно будут обрабатываться четыре диска с бекапируемых машин. И каждая таска, согласно всё тем же рекомендациям, для спокойной работы требует 2 Гб RAM.

Вспоминаем, на какой вопрос мы ищем ответ: если у меня будет вот столько данных, которые надо забекапить за вот такое количество времени, то сколько вычислительных ресурсов мне надо для этого заложить?

Итак, берём вводные: у меня 640 Тб данных, я хочу делать Per-VM бекап (потому что могу), на бекап у меня есть 8 часов ночью, а мой change rate - классические 10%.

Шаг первый: делим объём данных на имеющееся время и получаем некую скорость обработки данных, которой нам надо достичь. В моём случае получается (640 Тб* 1024*1024)/(8 часов * 60* 60) = 23075 Мб/с - такова должна быть пропускная способность нашей системы.

Шаг второй. Пусть жизнь наша нелегка, и всё, что у нас есть - это сервера, которые могут выдать только 100 Мб/с. Делим желаемое на имеющееся и получаем 23075\100= 230. Округляем в большую сторону до 231. Получилось количество необходимых ядер. Да, блюстители размерностей и единиц измерений могут прибывать в ужасе от таких переходов, но куда деваться. Для примера давайте ещё представим, что наши сервера не настолько древние и от гигабита пропускной способности в обморок не падают. Получится, что нам вполне хватит 24 ядра. Более чем посильное число для современного оборудования.

На третьем шаге умножаем количество ядер на рекомендованные 2 Гб на таск и получаем 24*2 = 48 Гб RAM. Да в ноутбуки уже больше ставят, если честно. А вот у коллеги с более старым железом получится 2312 = 462 Гб RAM. Уже более интересное число, но чего только не сделаешь, дабы успеть забекапиться вовремя.

Затем просто делим это цифры на желаемое количество проксей, округляем в большую сторону и получаем искомые параметры. Повторюсь, никто не запрещает вам использовать хоть десять прокси, хоть один. Просто выдавайте им соответствующие ресурсы, и всё будет здорово. У вас по 12 ядер в сервере? Отлично, 231/12 = 20 серверов по 24 Гб оперативки в каждом. И так далее.

И вспоминаем нюанс с инкрементами. Мы договорились принять, что у нас будет меняться по 10% данных в день. Подставляем в наши формулы: (640 Тб*0,1% * 1024*1024)/(8 часов * 60* 60)= 2 331 Мб/c / 100 Мб/c = 24 ядра * 2 Гб RAM на таск = 48 Гб RAM. Значит, при прочих равных для инкрементальных бекапов нам будем достаточно двух серверов, по 24 гига оперативки в каждом.

Вот и вся математика. Как видите, никакой магии тут нет и всё считается довольно просто. Да, в своих подсчётах мы используем некую общую пропускную способность в вакууме, а не берём конкретные цифры по скорости сети, дисковых полок и так далее, но кто кроме вас знает вашу инфраструктуру, её слабые и сильные стороны?

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

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

Я не буду кричать что первые плохие, а вторых надо гнать из профессии. Нет. Я только лишь предлагаю трезво взглянуть на суть VTL.

А в чём проблема?

Чтобы разобраться с вопросом о легитимности использовании VTL, давайте вспомним, зачем вообще нужны ленты. Это самое дешёвое, не самое быстрое, зато физически отчуждаемое устройство для хранения информации. Про дешевизну можем говорить, если посчитаем цену условного терабайта хранения. Прямо сейчас LTO-8 лента в режиме сжатия способна принять на себя 30 Терабайт данных, при цене около 9000 рублей. Для объективности можно даже откинуть маркетологов с их сжатием и записать только честные, физически наносимые 12,8 Тб. Для сравнения, за те же деньги можно взять SSD на один терабайт или обычный HDD на четыре. А тут сразу 12,8. Или даже 30, если повезёт. Да, для ленты ещё нужен привод, а лучше даже библиотека с роботом ценой в несколько сотен тысяч рублей, но там, где есть приличные объёмы данных, для которых встаёт вопрос о хранении на протяжении многих лет, это всё-таки дешевле, чем закупать дисковые полки и заниматься их обслуживанием.

Но из-за своей природы (пластиковая лента с магнитным слоем) у лент есть несколько очень неприятных моментов. Например, на ленту можно не слишком быстро писать данные, а потом очень долго и медленно их считывать. Особенно если речь идёт о файлике, который физически оказался в самом конце вашей кассеты. Пока вы будете ждать перемотки ленты на необходимое место, тут даже HDD с его задержками на раскрутку шпинделя и необходимостью двигать коромысло со считывающей головкой покажется манной небесной. Другая ленточная беда - невозможность изменять файлы. Файл, записанный на ленту, можно только удалить. Изменили полтора байта в вашем файле? Добро пожаловать в конец дорожки, кажется, там ещё оставалось место, чтобы перезаписать весь файл ещё раз.

И, конечно же, помним про возможность простого физического отключения. Вставили ленту в привод, записали на неё что-то, привод ленту выдал обратно, вы её убрали подальше, и голова ваша не болит. Лента лежит, собирает пыль, и ничего с ней не происходит. Диски так не умеют. Даже если и хочется вынуть диск сервера и убрать на полку, то придётся разбирать корпус и вырубать весь сервер. Если это дисковая полка, то корпус разбирать не придётся, но насиловать не рассчитанные на постоянное туда-сюда разъёмы тоже не очень хочется. А вот лентам для счастья ничего не надо. Ни электричества, чтобы постоянно крутить шпиндель, ни страха перед разболтавшимися разъёмами.

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

Все эти прекрасные особенности давно заприметили разного рода регулирующие гос.органы примерно всех стран. Если вы не знали, то есть довольно много компаний, от которых на законодательном уровне требуется хранить разного рода информацию по многу лет. Спросите, например, медиков, банки, страховщиков и так далее. Вам могут рассказать массу увлекательных историй про то, как они вынуждены обеспечивать сохранность данных своих клиентов на протяжении лет десяти-пятнадцати. Вы же не думаете, что кто-то в здравом уме будет покупать дисковую полку, задача которой будет заключаться в простаивании 99% времени? Да и диски придётся поменять не один раз за эти десять лет. Поэтому не только зарегулированные, но и обычные компании, где решили заняться архивным хранением, давно пришли к выводу, что ленты и только ленты.

Но есть тут один нюанс, который объяснит нам причины появления VTL почти тридцать лет назад. Представьте, что ваше основное боевое хранилище это дорогущий SAN, сделанный с использованием самых последних технологий своего времени. И вдруг выясняется, что к этому FiberChanel монстру надо подключить ленточную библиотеку по страшному и медленному SCSI интерфейсу. Полученная скорость работы вызовет у вас депрессию, не извольте сомневаться. И вот, после недельного запоя у вас появляется светлая мысль: А может ну их, эти ленты?. Но потом вы вспоминаете, что это Ну их может стоить многих денег вашей компании в виде штрафов от регулятора. Ну и весёлых приключений лично вам, если звёзды сойдутся особенно удачно. Поэтому у вас рождается очень хитрый план: а давайте вместо лент мы будем использовать всё те же диски, а чтобы рисовать красивые отчёты, мы напишем эмулятор, который будет подключаться к нашему софту, отвечающему за резервные копии, и будет тщательно кивать головой на все его команды к лентам.

И на тот момент это сработало. Появились эмуляторы, функциональность которых находилась на уровне архиватора: упаковать файлы в свой формат и радостно отчитаться по SCSI (или любому другому) порту о том, что ленточка старательно записана, робот её вынул и даже положил вот в такой вот слот в своей библиотеке. Самое натуральное переливание из пустого в порожнее под флагом имитации бурной деятельности. Но дабы не только ругать VTL на чём свет стоит, стоит всё же упомянуть и про их плюсы. Самый главный, действительно, это всё ещё скорость. Если вам совсем некуда девать деньги и ваш VTL пишет свои файлы на SSD, то вы победитель по жизни. Но если с деньгами не настолько всё хорошо, а весь фронт работ это записать буквально десяток плёнок, то диски будут дешевле, как ни крути. Если не верите, то просто посмотрите, сколько стоят современные LTO приводы. Ну и вишенка на торте - нет необходимости перематывать кассету на нужное место. Читай сразу откуда хочешь.

Поэтому главное что хочется сказать - не обманитесь заманчивыми плюсами VTL. Буква V значит Virtual, а все преимущества(и недостатки) лент исходят из их физической природы. Так что VTL может принести вам только моральное удовлетворение, но никак не решить задачу недорогого хранения отчуждаемых бекапов на случай аварии. Да и смысл интеграции с бекапным софтом уже давно пропал из-за наличия встроенных функций для перекладывания бекапов из одной корзины в другую. Например, в Veeam эта функция называется Backup Copy. Пользуйтесь на здоровье.

Да, есть ещё так называемые D2D2T системы, где VTL используется в виде кеша, а потом готовые файлы просто записываются на ленты. Правда, сейчас их будет правильнее называть D2D2C, где C это Cloud.

Препарируем VTL

Ну ладно, раз VTL это идеальная лаба, чтобы ознакомиться с функционалом ленточного бекапа, давайте таки развернём эту лабу и попробуем записать наши бекапы на ленту, хоть и виртуальную. Я долго выбирал между более хардкорным MHvtl и QUADstor с его симпатичным GUI, но в итоге остановился на втором исключительно из-за большей его популярности. Хотя оба проекта бесплатные и обеспечивают плюс-минус одни и те же функции. А производить все манипуляции я буду на CentOS.

Первым делом, конечно же, yum update && yum upgrade и ставим все необходимые пакеты:

yum install httpd gcc perl sg3_utils kernel-devel

Наверняка большая часть этих пакетов и так уже стоит, но вдруг вы такой же маньяк и начинаете с CentOS minimal. Также рекомендуется проверить, что установленные версии ядра и тулзов совпадают, а то в наших планах QUADstor компилировать, и лишние проблемы нам ни к чему. Так что сравниваем выводы uname -r и rpm -qa | grep kernel-devel

[root@centos ~]# uname -r3.10.0-1160.15.2.el7.x86_64[root@centos ~]# rpm -qa | grep kernel-develkernel-devel-3.10.0-1160.15.2.el7.x86_64

Если у вас циферки разошлись, то спасаемся yum upgrade kernel и ребутом.

С подготовкой закончено, и мы можем полноценно переходить к установке подопытного. В стандартных репозиториях его нет, поэтому на помощь нам приходит wget и официальный сайт. На момент февраля 2021 у меня получилось вот так:

wget https://quadstor.com/vtldownloads/quadstor-vtl-ext-3.0.51-rhel.x86_64.rpm

Теперь идём в директорию, куда скачался файл (если она у вас не стандартная), и устанавливаем пакет. Внимание: я это делают в чисто лабораторных целях и условиях, поэтому поэтому могу себе позволить делать всё от рута. А вы нет! Делайте все с правами рядового пользователя.

rpm -ivh quadstor.rpm

На что я получил отлуп по зависимостям (ох уж эти CentOS minimal)

rpm -ivh quadstor.rpmerror: Failed dependencies:libcrypto.so.10()(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64libcrypto.so.10(libcrypto.so.10)(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64libssl.so.10()(64bit) is needed by quadstor-vtl-ext-3.0.51-rhel.x86_64

Ладно, мы не гордые, идём и ставим compat-openssl10, так как это всё его библиотеки. И повторяем установку, которая в этот раз завершается успехом за пару минут, и мы становимся обладателями QUADstor, mini PostgreSQL сервера, где будут храниться данные конфигурации, и небольшого Apache Web Server для Web-GUI. Хотя никто не запрещает и дальше всё делать через консоль, но мы пойдём по более наглядному пути. Только перед этим нам надо запустить веб сервер и проверить, запустился ли демон VTL.

systemctl enable httpdservice httpd start/etc/rc.d/init.d/quadstorvtl start

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

Первым делом надо зайти в Physical Storage и выбрать диски для работы. По умолчанию QUADstor выбирает первый диск, который обнаруживает. Читай, диск с системой. У меня на скриншоте виден второй диск, подключённый к этой виртуалке, так что смело выбираю его кнопкой Add.

Сразу предложат добавить этот диск в один из Storage Poolов, которые надо создать заранее. Это некая логическая единица для смыслового объединения лент по какому-то признаку. Как видите, ничего супер-необычного здесь нет, весь джентльменский набор: дедупликация для экономии места, WORM кассеты и репликация кассет. Но нам сейчас это всё не так интересно, поэтому ограничимся стандартным пулом.

Но самое интересное находится в секции Virtual Libraries. Здесь мы выбираем, хозяина какой именно железки мы будем из себя изображать. А то и нескольких сразу, ведь кто нам запретит? Так уж сложилось, что душой я за HP, поэтому хотел выбрать себе HP MSL 6000 с двумя приводами Ultrium 6250, но потом передумал и для наглядности выбрал ветерана ленточных боев - ESL 9000.

И теперь самое время закупитьнарисовать себе кассет побольше. Хотя совсем уж много не получится, ибо ленты хоть и виртуальные, но информация хранится на совершенно реальных нерезиновых дисках. Но вся прелесть VTL в том, что в любой момент можно всё отредактировать как надо и не думать о проблемах с железом.

На этом с настройкой VTL всё, и хочется перейти в интерфейс Veeam, дабы скрестить его с библиотекой. Однако мы не ищем лёгких путёй и подключим библиотеку к другой Windows машине, которая будет работать у нас в качестве Tape Server. Для чего заходим на этот сервер, запускаем iSCSI сервис и iSCSI инициатор. Там находим нашу библиотеку любым из доступных способов и подключаемся к ней. По умолчанию будет использоваться порт 3260, так что может потребоваться добавить соответствующее правило на вашем фаерволе.

Тут наступает важный момент: надо обязательно открыть Device Manager и посмотреть как определились новые устройства. Крайне рекомендуется поставить драйвера, чтобы избежать проблем при работе с библиотекой. Veeam использует стандартные системные вызовы, поэтому если система может работать с библиотекой, Veeam тоже будет работать. А нет драйверов - нет мультиков. Так что если у вас старьё вроде того, что я добавил в свою лабу, система сама всё поставит. Если что-то новое, то качайте с сайта производителя. Технически, Veeam может работать и с универсальным Microsoft Tape Format (MTF), но оригинальные драйвера всегда в приоритете.

И теперь (наконец-то) можно идти на сервер Veeam и открывать вкладку Tape Infrastructure. Где первым делом запустим мастер добавления Tape Server.

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

Если всё было сделано правильно, то Veeam начнёт бодро двигать туда-сюда кассеты, проверяя и внося их в свой стандартный медиа пул.

Кстати, если в этот момент зайти в лог VTL, то там все эти перемещения кассет тоже будут отображены. Бывает очень удобно смотреть на процесс с двух сторон.

Но мы отвлеклись, так что давайте вернёмся в Veeam и проверим, что всё добавилось верно.

Как мы видим на скриншоте, библиотека определилась верная, приводы на месте, а количество кассет совпадает с заданным. Все кассеты находятся в медиа пуле Free, так как мы провели инвентаризацию. Если её пропустить, то все неизвестные ленты попадут в пул Unrecognized. Можно принимать поздравления, ибо всё действительно работает как и должно.

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

Итак, запускаем мастер Backup to Tape, задаём имя джобе и на втором шаге добавляем бекап, который хотим хранить на ленте. Технически можно добавить не просто бекап, а хоть целый репозиторий с бекапами, но мы такого делать не будем. Просто берём один красивый бекапчик.

Поскольку мы только что подключили нашу ленточную инфраструктуру, странно будет, если у нас уже обнаружатся разные медиа пулы. Их еще нет, поэтому на следующем шаге надо создать хотя бы один.

Про медиа пулы, опять же, отсылаю вас читать документацию и статьи коллег, а для наших целей отлично подойдёт согласиться на все предлагаемое по умолчанию и добавить все имеющиеся кассеты. Главное, не забудьте на шаге Options выбрать использование сразу нескольких приводов. Можно ограничиться и одним, но зачем это делать, если мы создали два?

Для любителей настроек, с которыми можно поиграть, на шаге Options есть пункт Advanced, внутри которого есть вкладка Advanced и несколько вариантов настроек. В принципе, заходить сюда нет никакой необходимости, но если хочется попробовать разные варианты, то почему нет.

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

Ну а почему бы и нет? Имею право на мечты! Разве не для этого были придуманы VTL решения?

И на последок, ловите ссылку на раздел документации посвящённый работе с ленточными девайсами. Скорее всего там вы найдёте ответы на все свои вопросы.

Функция CDP (она же Continuous Data Protection) для многих сейчас видится манной небесной. Ведь она позволяет свести риски потери данных к около-нулевым значениям (RTO и RPO - единицы секунд), при этом не используя тормозящие всё вокруг себя снапшоты, и не зависеть от ограничений классических вариантов репликации.

Вот об этом мы сегодня и поговорим: что это за магия такая, как она работает и как мы её реализовали в Veeam Backup & Replication v11.

Achtung! Прочтение данной статьи никак не освобождает вас от необходимости изучить официальную документацию. Написанное ниже следует понимать скорее как выжимку из ключевых моментов с дополнениями, нежели как более правильную или альтернативную версию документации. И пока далеко не ушли, очень советую особенно тщательно изучить раздел Requirements and Limitations. Ещё никогда он не был настолько важен, как в случае с CDP. Почему-то именно здесь у многих появилось какое-то очень своё видение этой технологии, что мешает трезво оценивать её реальные возможности. Особенно часто все любят упускать слово Clusters. Может в это весна виновата, но суть одна: нет кластеров - нет мультиков. Совсем.

Зачем CDP нужен этому миру

Начинаем по порядку: а какие проблемы может решить CDP и кому он нужен?

Отвечать будем по порядку поступления вопросов, чтобы ответ на предыдущий помогал понять ответ на следующий. Итак, CDP - это ещё один вид репликации виртуальных машин. Вот так всё просто. На этом всё. Всем спасибо, все свободны. Шутка.

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

Соответственно, проблема, которую помогает нам решить CDP - это обеспечение минимальных значений RTO и RPO. Получается, что это история для самых важных приложений, где допустимый простой может измеряться минутами или даже секундами. А лучше, чтобы его вообще не было. Разные умные люди считают, что под эти требования попадает не более 5% нагрузок. Просто от их функционирования зависят остальные 95%, так что обеспечение их бесперебойной работы становится основной задачей IT отдела.

Хорошо, но чем тогда нас не устраивают классические реплики? В том же Hyper-V, технически, можно реализовать репликацию каждые пять секунд. Вот же оно! Но нет. Вся проблема в снапшотах и задержках, которые они тянут за собой. Как ни крути, но создание снапшота - это весьма небанальный процесс (просто посмотрите на эту обзорную схему работы VSS), происходящий сначала на уровне машины, а потом и хоста. Который неизбежно приводит к задержкам и накладным расходам. А потом снапшот надо удалить, а в процессе всех этих операций не угробить машину и работающие на ней приложения (что очень запросто, уж поверьте). Да и в целом, весь этот процесс выглядит довольно громоздко: надо создавать пачку снапшотов (на уровне ОС, потом на уровне гипервизора, а потом ещё и на уровне датасторы может понадобиться), выхватить пачку получившихся данных (не просто прочитать файлик, а получить его в виде дельты двух состояний), куда-то их все махом переложить, корректно удалить снапшоты в обратном порядке и дать отмашку гостевой ОС, что можно продолжать спокойно работать.

Так что если снапшоты можно исключить, их надо исключить.

Как работает CDP

Видя всё это безобразие, разработчики из VMware как-то сели крепко подумать и решили выпустить некое API, которое сейчас известно под именем VAIO. Фактически, это технология, позволяющая сделать классический I/O фильтр, который даёт возможность следить за I/O потоками гостевых машин и делать что-то с этим знанием. Причём с момента включения этого фильтра ни один изменившейся на диске байт не останется без нашего внимания. А дальше дело за малым: берём эти блоки, копируем из одной машину в другую - и мы восхитительны. Буквально пара недель работы программистов, неделька на тестирование, и можно релизить.

Хотелось бы так, но нет. На практике всё несколько сложнее. Давайте разбираться.

Вот так выглядит общая схема работы. Для видавшего виды VBR пользователя здесь знакомо только слово Proxy. И, пожалуй, да, на прокси вся схожесть с классическими схемами работы и заканчивается.

Погнали по списку:

• Координатор. Умывальников начальник и мочалок командир. Управляет всеми процессами, отвечает за связь с vCenter, говорит другим компонентам, что делать, и всячески следит, чтобы всё было хорошо. На местах выглядит как Windows сервис. Единственный, кто знает про существование таких вещей, как vCenter и виртуальные машины. Все остальные работают только с дисками. Поэтому всё, что не связано с репликацией контента, делает координатор. Например, создаёт виртуалку на таргете, к которой мы прицепим реплицируемые диски.

• Source filter. Та самая штука, которая занимается перехватом IO запросов. Соответственно, работает уже на ESXi. Дабы повысить надёжность и производительность, один инстанс фильтра работает с одним виртуальным диском. Фильтры держат связь с демоном.

  Технически, фильтр - это dll библиотека, живущая внутри виртуальной машины. И если с ним что-то случается (залипла память, скрешился и т.п.), то следом прилетает виртуалке, внутри которой он работает. Поэтому жизнеспособности фильтров было уделено огромное внимание. Ну и если вы сомневаетесь по поводу прямоты рук создателей фильтра: такие штуки можно устанавливать на хосты только после прохождения строгой сертификации получившегося изделия со стороны VMware.

Важно: VBR производит установку на кластер. Довести фильтр до каждого хоста - это уже задача самой VMware. Причём если вы добавляете новую ноду в кластер, то наш бандл на него будет установлен автоматически. Зачем? Давайте представим, что произойдёт, если в кластере появится новая нода и для какой-то из машин сработает vMotion на эту ноду? Всё верно - CDP реплика сломается. Однако вся эта автоматика не отменяет необходимости пройти через Manage I/O filters визард - для актуализации настроек. Поэтому, если добавили ноду, то быстренько проходим Manage I/O filters визард, который обнаружит новичка и всё настроит.

• Source Daemon. Используется один на каждый хост. В отличие от мифического фильтра, который где-то там работает, демон - это вполне конкретный процесс на хосте. Отвечает за связь с координатором и общается с прокси на предмет поиска оптимального маршрута трафика. Работает по медленному TCP, так как шустрый UDP не гарантирует доставку. И да, это именно тот случай, где это критично и необходимо.

  Зачем нужна прокладка в виде демона и почему бы фильтру самому не работать с прокси? Это ограничение технологии со стороны VMware, не позволяющее фильтру работать с внешней сетью. То есть фильтр с демоном связь установить может, а с прокси нет. Это называется by design, и ничего с этим не поделаешь. Во всяком случае, сейчас. И напомню: демон не знает ни про какие виртуальные машины. Он работает с потоками данных от дисков. И ничего другого в его мире не существует. Поэтому диски одной машины могут обрабатываться сразу несколькими прокси. Мы, конечно, стараемся отвозить диски одной машины через один прокси, но если она не справляется, то подключится другая. И это нормально!

• Source Proxy. Агрегирует в себе всю информацию, полученную от фильтров через демонов. Хранит всё строго в RAM, с возможностью подключения дискового кэша, если оперативка кончилась. По этому очень (ОЧЕНЬ!) требователен к RAM, дисковому кешу и задержкам на сети. Так что только SSD и прочее адекватное железо.

  Прокси занимается составлением так называемых микроснапшотов, которые отправляются дальше. Данные перед передачей обязательно дедуплицируются: если в каком-то секторе произошло 100500 перезаписей, то до прокси дойдут все, но с самого прокси будет отправлена только одна последняя. Так же, само собой, всё сжимается и шифруется.На местах прокси представляют собой Windows машины, которые могут взаимозаменять друг друга, переключать нагрузку и так далее.

• Target Proxy. Всё то же самое, но в обратном порядке. Принимает трафик от сорсных проксей, расшифровывает, разжимает, отправляет дальше. Так же может быть как физический, так и виртуальный.

• Target Daemon. Занимается записью данных на датастор. Полная копия сорсного демона.

• Target Filter. В нормальном состоянии находится в выключенном виде. Начинает работать только во время фейловера и фейлбека, но об этом позже.

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

Немного промежуточных деталей

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

Как мы видим, процессы, связанные с CDP, довольно плотно интегрированы в сам хост. Так что при выполнении многих операций надо быть предельно внимательным. Например, апгрейд/удаление VAIO драйвера происходит строго через maintenance mode. Установка, что хорошо, такого не требует. На случай отсутствия DRS предусмотрена защита, которая не даст запуститься процессу, однако это же IT, и бывает тут всякое. Поэтому действовать надо осторожно и внимательно.

И ловите бонус: фильтр с хоста можно удалить командой:

esxcli software remove -n=veecdp.

Но есть проблема: как я писал выше, установкой фильтров на хост занимается VMware в автоматическом режиме, поэтому при выходе из mm фильтр появится снова. Так что правильно удалять фильтр через кластер. Наименее зубодробительный способ - это через powercli:

Get-VAIOFilter |Remove-VAIOFilter

И дальше по обстановке.

Мой любимчик - DNS. Должен работать как часы, по принципу каждый-каждого, ибо все мы знаем, что Its always DNS. Если у вас на VBR сервере используется один DNS сервер, а в vCenter и на хостах другой, то в этом нет никакой проблемы до тех пор, пока они могут резолвить неймспейсы друг друга. То есть vCenter должен уметь зарезолвить VBR и хосты. А хосты должны уметь резолвить VBR и vCener. И так далее.

И, конечно же, не забудем обрадовать ненавистников разного рода устанавливаемых на гостевую ОС агентов и сервисов. Для CDP ничего такого делать не надо, и даже админские креды никому больше не нужны (если только вы готовы отказаться от VSS точек с application consistent состоянием). Наконец-то угнетатели повержены и можно спать спокойно. Всё работает исключительно за счёт магии VAIO API.

Retention

Самое время упомянуть альфу и омегу запросов в саппорт - ретенш. А между прочим, их тут сразу целых два!Вот это поворот! (с)

На длинной дистанции мы используем Long-term retention, гарантирующий консистентность на уровне приложений(application aware). Делается это с помощью VSS и требует предоставления админской учётки от гостевой ОС. Выглядит это как создание точек отката с определённой периодичностью (например, раз в 12 часов), которые хранятся несколько дней.

И второе - это Short-term Retention, где гранулярность отката может доходить до 2 (двух!) секунд, но гарантируется только crash-consistent восстановление. Для short-term указывается значение RPO - как часто сохранять состояние дисков - и сколь долго хранить эти изменения. Можно понимать это как количество времени, которое мы будем хранить наши RPO точки. На скриншоте ниже мы будем хранить данные с нарезкой по 15 секунд за последние 4 часа.

Расписание, само собой, гибко настраивается, позволяя, например, обеспечивать crash-consistent только в офисное время, а в ночное переключаться на редкие, но application-consistent точки.

Если подходить глобально, то вариантов сделать фейловер у нас два: прямо сейчас по кнопке Failover now или создав Failover Plan. Соответственно, если случилась авария, то мы можем сделать фейловер нашей реплики в следующих режимах:

• Откат на последнее состояние (crash-consistent)

• Восстановиться на нужный нам момент времени в режиме Point-in-time (crash-consistent)

• Откатиться на Long term точку (здесь можно выбрать между application-aware и crash-consistent)

А failback и permanent failover делаются по правилам обычных старомодных реплик, так что останавливаться на этом не буду. Всё есть в документации.

Совет: в выборе нужного момента времени при Point-in-time ресторе очень удобно двигать ползунок стрелочками на клавиатуре ;)

Как работает CDP ретеншн

И прежде чем мы начнём обсуждать, почему вы поставили хранить три точки отката, а на диске их двадцать восемь, давайте посмотрим, что вообще будет храниться на таргетной датасторе.

• .VMDK Тут без сюрпризов. Обычный диск вашей машины, который создаётся в момент первого запуска репликации.

• .TLOG и .META - логи и метаданные транзакций. Всё для того, чтобы ничего не потерялось. Также они позволяют сделать откат на произвольный момент времени.

• VM-000X.VMDK Дельта диски, коих может быть огромное количество. И не думайте, что каждый дельта диск - это точка отката. Это просто хранилища блоков данных, жестко связанные с файлами логов транзакций. Примерно как в базах данных. Когда вы будете делать фейловер, Veeam выстроит цепочку из нужных дельта дисков и первоначального VMDK. А с помощью лога транзакций найдёт необходимые блоки данных, которые фильтр применит к базовому диску при запуске машины. Это тот единственный момент, когда нам нужно включить Target Filter.

Short-term retention

Теперь рассмотрим, как это работает.

• В первый момент времени на таргете нет ничего, поэтому, чтобы начать работать, нам надо взять и в лоб поблочно скопировать VMDK файл с сорса на таргет.

Интересный факт: в интерфейсе VBR иконки успешно переехавших машин окрашиваются в синий. В то время как их менее успешные товарищи остаются серыми. Если время, которое вы выделили на первичную синхронизацию, уже прошло, а машины так и не посинели, то надо разбираться, что им мешает. Правильный и простой вариант действий в этом случае: обратиться в сапорт. Более долгий и увлекательный - копаться в логах самому. Только учтите, что на тему CDP логов можно ещё одну статью смело писать, так что лучше доверьте это дело профессионалам.

Совет: если тащить по сети огромный VMDK вам нет никакого удовольствия, то Seeding и Mapping вам в помощь. Они позволяют перевести ваши файлы на таргетный хост хоть на флешке в кармане, в дальнейшем подключив их к заданию.

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

Возникает закономерный вопрос: каков размер этих самых блоков? Он динамический и зависит от размера диска. Для простоты можно считать, что 1 Тб диска соответствует 1 Мб блока.

• Как только VMDK перевезён, можно начинать создавать дельта диски. Для чего фильтр и демон начинают отслеживать IO машины, отправляя по сети всё, что пишется на машине.

• Этот поток сознания, приходя на сорс прокси, проходит через процедуру отбрасывания лишних блоков. То есть если некий блок за период репликации был перезаписан несколько раз, то в дельту уйдёт исключительно последнее его состояние, а не вообще все. Это позволяет сохранять вагон ресурсов и два вагона пропускной способности вашей сети.

• Рядом с дельта диском создаётся транзакцонный лог.

• Если лог становится слишком большим, то создаётся новый дельта диск.

• И так всё работает до достижения выбранного Retention policy. После чего Veeam смотрит на содержимое лога.

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

• Если оказывается, что в логе нет вообще ничего, необходимого для создания новых точек восстановления, такой файл сразу удаляется.

Примечание: Соблюдение Retention Policy довольно важно. Однако поддержка CDP реплики в боевом состоянии ещё важнее. Поэтому в механизм заложена потенциальная возможность временного расширения периода хранения до 125% от первоначального.

Long-term retention

Служит логическим продолжением short-term retention. То есть всё работает ровно так, как и написано выше, пока не наступает момент создать long-term точку.

• В этот момент создаётся особый дельта диск. Внешне он не отличается от других, однако во внутренней логике он помечается как long-term delta.

• Репликация продолжает идти своим чередом.

• Когда подходит время для срабатывания short term, то все предыдущие логи и дельта диски (если их несколько) просто удаляются.

• Теперь всё считается от этой long-term точки. Она остаётся нетронутой и высится как глыба.

• Затем создаётся новая long-term точка, и цикл замыкается.

• Когда подходит время, то самая первая long-term точка инжектируется в базовый VMDK.

Про логику транзакций

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

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

Отсюда два важных следствия:

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

• На втором участке задержка уже не критична. Если даже в какой-то момент времени мы не успеваем получить подтверждение от таргетного демона, то данные остаются в кеше сорсного и таргетного прокси и будут переданы ещё раз. Если кажется, что такое кеширование избыточно, то это кажется. Сети сейчас, конечно, быстрые, но зачем лишний раз лезть далеко, если можно попросить данные ближе? В логе джобы в этот момент возникнет предупреждение, что RPO нарушено, но ничего критичного ещё не случилось. Позднее данные будут довезены до таргета.

Что под капотом у фильтров

Теперь, когда мы разобрались на базовом уровне в устройстве и принципах работы CDP, давайте посмотрим более внимательно на работу отдельных компонентов. А именно фильтров. Ведь именно от их красивой работы зависит всё остальное. И как мы все прекрасно понимаем, ровно и красиво может быть только в лабораторных условиях. Именно там у нас всегда стабильный поток IO операций, нет резких всплесков нагрузки, сетевые пакеты никуда не пропадают, и все графики выглядят как прямая рельса, уходящая за горизонт.

Именно из-за таких расхождений с реальностью у фильтров есть два режима работы. Clean Mode и Dirty Mode. В первом варианте у нас всё хорошо, и все измененные блоки мы успеваем отправить вовремя, а на принимающей стороне успевают их принять и уложить в требуемое место. Но как только над нами сгущаются тучи и мы не успеваем передать очередную порцию данных, CDP фильтр переключается во второй режим. Вернее, он получает команду от демона, что у того переполнена очередь на отправку и новые данные хранить негде. После чего фильтр перестаёт передавать данные, а только ведёт учёт изменённых блоков. Такие блоки данных помечаются как DirtyBlockMap. Единственное, что можно сделать в этой ситуации - это ждать возвращения стабильного канала связи и отмашки, что всё успешно записалось на таргет. Как только принимается решение, что связь удовлетворяет нашим потребностям, помеченные блоки передаются ещё раз, и в случае успеха фильтр переключается обратно в Clean Mode.

Немного сухих цифр: кэш каждого из фильтров - на всё про всё 32 МБ. Вроде мало, но больше и не надо. Задача фильтра - считать блок и как можно быстрее поставить в очередь сорс демона. Там кэш - уже 2 ГБ заранее выделенного RAM. Дисковый кеш прокси задаётся пользователем вручную. И в целом надо помнить, что архитектура CDP подразумевает максимальное наполнение кеша всех из компонентов в надежде, что данные всё же получится отвезти на таргет. И только когда кончается вся свободная память, реплика останавливается с ошибкой.

Вот так вот можно изобразить на любимых всеми квадратиках с буквами режимы работы. В данном примере у нас установлено RPO 10 секунд, из которых пять секунд (половина RPO) мы отслеживаем изменения данных, а вторую половину времени пытаемся передать последнее их состояние. То есть, промежуточные, как я говорил выше, нас не интересуют.

А вот что случается, когда мы не получаем подтверждение доставки от таргета. Данные мы собрали, однако передать их не можем. В этот момент Veeam начинает сохранять в сторонку номера таких блоков. И только номера, никаких данных. Почему? Потому что когда связь восстановится, нам надо передать актуальное состояние блоков.

Примечание: Чтобы администратор спал спокойней, предусмотрены два оповещения, скрывающихся под кнопкой RPO Reporting. Фактически они просто считают, сколько данных за указанный промежуток времени мы можем потерять. И бьют в набат, если что-то пошло не так.

Инфраструктура

Обычно, когда заходит речь о проработке какой-либо инфраструктуры, все сразу начинают думать про CPU и RAM. Но только не в этот раз! Здесь надо начинать с поиска вашего сетевика, чтобы он сделал вам сеть с наикратчайшим маршрутом, с 10 Gbit+ линками, и не забыл включить MTU 9000 (Release Jumbo frames!!!) на всём протяжении маршрута. Согласно нашим тестам, такой набор нехитрых действий позволяет добиться прироста производительности почти на 25%. Неплохо, да?

Но не бросаем сетевика на полдороге и тащим его к тем, кто занимается серверами: для VMkernel должны стоять выделенные физичеcкие NIC. Если нет - не приходите жаловаться на тормоза. Ибо сеть, скорее всего, будет забита под потолок своих возможностей. Но вообще, чисто технически, минимально нужны гигабитные карточки и задержки в пределах 80 мс.

Теперь сетевика можно уже отпустить и переключиться, например, на таргетный сторадж. Тут всё очень просто: всегда используйте выделенный сторадж. Процесс записи невозможно как-то замедлить, попросить подождать пока идёт транзакция от другого приложения, и так далее. Нет, сторадж будет молотить на весь свой ценник и вряд ли будет очень рад дополнительным нагрузкам. Хотя, конечно, тут всё зависит от вашего железа. Ну и роли прокси, конечно же, лучше выдавать выделенным машинам. Насчёт того, физическим или виртуальным - тут мнения расходятся. Лично я за физические, но правильно будет протестировать на месте.

И общий совет на все случаи жизни: десять маленьких CDP политик всегда будут работать лучше и стабильней, чем одна большая. Что такое маленькая политика? Это до 50 машин или 200 дисков. В мире большого энтерпрайза это считается за немного. Технически, опять же, здесь ограничений нет, и проводились успешные тесты аж до 1500 машин и 5000 дисков. Так что лучше, опять же, протестировать на месте и найти оптимальный для себя вариант.

Немного о прокси

И хотя кажется, что прокси серверам в схеме CDP отведена роль тупых молотильщиков трафика, без их успешного взаимодействия всё остальное теряет смысл. И задачи там решаются достаточно серьёзные, так что не будем принижать их вклад в общее дело.

Что хочется сказать про этих ребят:

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

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

• В идеальном мире на один ESXi - один прокси.

• А вот физический или виртуальный на том же хосте - этого вам никто не скажет, и надо тестировать. Часто бывает, что виртуальный оказывается быстрее физического.

• Да и вообще, общая логика такова, что чем больше вы сможете развернуть прокси серверов, тем лучше будет результат. Особенно если речь идёт о репликации между удалёнными дата центрами.

Также самые внимательные заметят, что на шаге назначения проксей есть кнопка Test с таинственным набором цифр внутри.

Давайте разбираться что же это такое и откуда оно взялось. Все эти скорости и количества являются ничем иным, как усреднёнными максимумами за последний час, полученными от vCenter. То есть это не мы что-то там померили в моменте, ловко запустив какие-то таинственные тесты, а такова родная статистика хостов за последний час.

Давайте теперь пройдёмся по строчкам.

Source Proxy CPU: количество ядер CPU на всех доступных проксях, которые могут работать в качестве сорса. Видим vCPU, но читаем как ядра CPU.

Source Proxy RAM. Здесь уже посложней будет. Цифра перед скобками показывает, сколько оперативки нам может понадобиться для данной CDP политики.

Формула расчёта довольно простая: RPO* пропускную способность.

Пропускную способность кого/чего? Да всех дисков всех вируталок, участвующих в этой политике. Напоминаю, что берётся максимальное значение за последний час.

То есть предположим, что наш RPO - 15 секунд, и что диски выдают 150 Мб/сек. Значит, нам понадобится 2250 Мб RAM.

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

Source Proxy Bandwidth. Здесь опять всё просто. Число перед скобками мы получаем от vCenter, а число в скобках считается на основе доступного количества ядер с округлением до целого. Если мы шифруем трафик, то это 150 Мб/с на ядро. Если не шифруем, то 200 Мб/с на ядро.

Target Proxy CPU. Всё ровно так же, как у сорса: взяли и посчитали все доступные ядра на доступных проксях.

Target Proxy RAM. Хочется, как и в предыдущем пункте, сказать, что всё такое же, но нет. Здесь в формулу для расчёта внесён поправочный коэффициент 0.5. А значит, что если мы за те же 15 секунд хотим обработать 150 Мб/c от дисков, то понадобится нам уже только 1125 RAM (вместо 2250, как это было с сорсом).

Target Proxy Bandwith. Здесь тоже не обошлось без скидок. Считаем, что одно ядро при шифровании трафика будет обрабатывать 350 Мб/c, а без шифрования - все 400 Мб/c.

И помним важное: таргет и прокси меняются ролями в момент фейловера. То есть вся схема начинает работать в обратную сторону. Поэтому на таргете и есть неактивный фильтр, который оживает в момент фейловера. А фильтр на бывшем сорсе, соответственно, выключается.

Быстрое Ч.А.В.О. в конце

Как добавить в CDP Policy выключенную машину?

Никак. Виртуалка выключена > фильтр не работает > передавать нечего.

Какие версии vSphere поддерживаются?

Ну я же просил - читайте документацию, там всё есть. Но пользуйтесь пока я добрый: 6.5, 6.7, 7.0

Хочу минимальное RPO, чтобы ну вообще ничего не потерялось.

Если у вас железо хорошее (прям хорошее-хорошее, а не вам кажется, что хорошее), то вполне реально добиться RPO в 2 секунды. А так, в среднем по больнице, вполне реально обеспечивать 10-15 секунд.

А что с vRDM?

Всё отлично поддерживается.

А можно CDP прокси назначить и другие роли?

Назначайте, мы не против. Только следите за соответствием доступных ресурсов предполагаемым нагрузкам.

А можно CDP реплику, как и обычную, использовать для создания бекапов?

Нет. Во всяком случае сейчас.

Я могу запустить CDP реплику из консоли vCenter?

Нет. С точки зрения vCenter там какой-то фарш из дельта дисков, поэтому он выдаст ошибку зависимостей.

А если я руками удалю CDP реплику из Inventory в vCenter?

Умрут все id и всё сломается. А вы чего ожидали?

А если таргетная стора будет чем-то очень загружена?

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

А что с Hyper-V?

Это вопрос к Microsoft.

Немного полезных ESXi команд

Убить daemon сервис:

# ps | grep iof# kill -9 <PID>

Остановить/запустить daemon сервис:

# /etc/init.d/iofilterd-vvr stop/start

Полюбопытствовать насчет последних логов демона:

# tail -n 100 -f /var/log/iofilterd-vvr.log

Выяснить, сколько памяти потребили все демоны:

# vsish -e get /sched/memClients/[iofilterd-PID]/SchedGroupID

# memstats -r group-stats -s name:min:max:eMin:rMinPeak:consumed:flags -g [iofilterd-ScheddGroupID] -u mb

Проверить установку пакета фильтра. Он выглядит как обычный vib

# esxcli software vib list | grep veecdp

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

До недавнего беспокойного времени для создания резервных копий критичных данных я использовал стандартное средство операционной системы Windows 10 - "История файлов" ("File history"). Периодически данные со стационарного ПК сохранялись на внешний HDD, подключаемый через USB интерфейс, что меня вполне устраивало и успокаивало мою психику.

Одним субботним утром меня озадачил вопрос: "А смогу ли я восстановить свои данные на другой системе?" В качестве испытуемого был выбран ноутбук с системой Windows 10. После большой небольшой пляски с бубном данные были восстановлены, но неприятным сюрпризам стало то, что при сравнении количества папок и файлов было обнаружено расхождение. Данный факт меня опечалил и побудил подойти к вопросу организации резервного копирования данных более ответственно. После непродолжительного поиска в сети Internet мой выбор пал на Open Source систему Bareos. Процесс настройки системы не был для меня простым и интуитивным, было затрачено значительное количество времени. Память человеческая имеет прекрасную способность забывать информацию, что побудило меня составить "шпаргалку" на будущее, коей спешу с Вами поделиться.

Описание задачи

На стационарном ПК с ОС Windows 10 x64 на локальном диске DATA (D:) расположен каталог проекта "test". Необходимо организовать резервное копирование всех файлов вышеуказанного проекта на внешний HDD - BACKUP (E:), за исключением подкаталогов "target".

Разработка проекта ведётся в будние дни, поэтому копирование производить в автоматическом режиме по графику:

• полное - по пятницам в 18:30;

• инкрементальное - с понедельника по четверг в 18:30.

На компьютере на локальном диске C: установлена система Bareos версии 19.2.7 x64. Установка произведена "по умолчанию" (со всем соглашаемся и нажимаем "далее"), тип установки "Full SQLite":

Выполним нижеперечисленные действия по порядку.

Куда?

Создадим ресурс "Устройство" ("Device") и опишем его в файле C:\ProgramData\Bareos\bareos-sd.d\device\RemoteStorage.conf:

Device {  # имя устройства, обязательное  Name = RemoteDevice                  # тип данных, обязательное   Media Type = File                # где хранить тома, обязательное    Archive Device = E:/             # тома устройства именуются автоматически  LabelMedia = yes;                    # поддерживает произвольный доступ  Random Access = yes;                  # сканируется на наличие томов  AutomaticMount = yes;            # может ли быть отсоединено    RemovableMedia = yes;          }

Создадим ресурс "Хранилище" ("Storage"), соответствующий ресурсу Device, и опишем его в файле C:\ProgramData\Bareos\bareos-dir.d\storage\Remote.conf:

Storage {  # имя устройства, обязательное   Name = Remote                        # имя или IP адрес, обязательное  Address = localhost                  # пароль для доступа к Storage-сервису, обязательное  # ВЗЯТЬ ОТСЮДА C:\ProgramData\Bareos\bareos-sd.d\director\bareos-dir.conf  Password = "TFso/Fr6YDeuei/QYtg2bDLaS9dDkMgRvSPefKr88FnR"   # имя соответствующего ресурса Device, обязательное  Device = RemoteDevice  # тип данных, должен совпадать с типом данных соответствующего Device, обязательное  Media Type = File}

Создадим ресурс "Пул" ("Pool") для полного копирования и опишем его в файле C:\ProgramData\Bareos\bareos-dir.d\pool\TestFull.conf:

Pool {  # имя пула, обязательное  Name = TestFull  # повторное использование устаревших томов  Recycle = yes                         # усечение устаревших томов  AutoPrune = yes            # срок хранения данных в томах  Volume Retention = 365 days           # предельный размер тома  Maximum Volume Bytes = 50G      # предельное количество томов  Maximum Volumes = 100                 # формат имени для томов "TestFull-<id-тома>"  Label Format = "TestFull-"          }

Создадим ресурс "Пул" ("Pool") для инкрементального копирования и опишем его в файле C:\ProgramData\Bareos\bareos-dir.d\pool\TestIncr.conf:

Pool {  # имя пула, обязательное  Name = TestIncr  # повторное использование устаревших томов  Recycle = yes                         # усечение устаревших томов  AutoPrune = yes            # срок хранения данных в томах  Volume Retention = 30 days           # предельный размер тома  Maximum Volume Bytes = 1G      # предельное количество томов  Maximum Volumes = 100                 # формат имени для томов "TestIncr-<id-тома>"  Label Format = "TestIncr-"          }

Что?

Создадим ресурс "Набор файлов" ("FileSet") и опишем его в файле C:\ProgramData\Bareos\bareos-dir.d\fileset\TestFileSet.conf:

FileSet {  # имя набора файлов, обязательное  Name = "TestFileSet"  # что будем копировать  Include {  Options {    Signature = MD5         # хеширование, применяемое для файлов    WildDir = "*target"     # шаблон для исключения каталога    Exclude = yes           # исключить файлы по шаблону    }    File = "D:/test"          # каталог, подлежащий копированию  }}

Когда?

Создадим ресурс "Расписание" ("Schedule") и опишем его в файле C:\ProgramData\Bareos\bareos-dir.d\schedule\TestSchedule.conf:

Schedule {  # имя расписания, обязательное  Name = "TestSchedule"  # тип копирования, используемый пул и время запуска  Run = Level=Full Pool=TestFull fri at 18:30  # тип копирования, используемый пул и время запуска    Run = Level=Incremental Pool=TestIncr mon-thu at 18:30}

Кто? Как?

Создадим ресурс "Задание" ("Job") и опишем его в файле C:\ProgramData\Bareos\bareos-dir.d\job\backupTest.conf:

Job {  # имя задания, обязательное  Name = "backupTest"  # имя используемой File-службы  Client = "bareos-fd"  # набор файлов  FileSet = "TestFileSet"  # имя используемого Message-ресурса, обязательное  Messages = "Standard"  # пул, обязательное  Pool = "TestFull"  # расписание  Schedule = "TestSchedule"  # устройство  Storage = "Remote"  # тип, обязательное  Type = "Backup"  # где хранить файл начальной загрузки  Write Bootstrap = "E:/%c.bsr"}

Активация задания копирования

Перезапустим службы Bareos, чтобы применить внесённые нами изменения:

• Bareos Storage Service ("Bareos-sd");

• Bareos Director Service ("Bareos-dir").

После этого наше задание "backupTest" активировано, проверим это. Зайдём в панель управления Bareos по адресу http://127.0.0.1:9100/ (логин: admin, пароль: admin). Перейдём в раздел "Расписание" ("Schedules") на вкладку "Статус планировщика" ("Status schedules") и убедимся, что наше задание присутствует в расписании.

Запуск копирования вручную

Перейдем в раздел "Задания" ("Jobs") на вкладку "Запуск" ("Run"). В поле "Задание" ("Job") выберем наше задание "backupTest". В поле "Уровень" ("Level") выберем значение "Full" и запустим задание, нажав "Submit".

При этом будет выполнено полное копирование. Для выполнения инкрементального копирования выберите в поле "Уровень" ("Level") значение "Incremental", в поле "Пул" ("Pool") - "TestIncr".

Ход выполнения любых заданий можно контролировать в разделе "Панель" ("Dashboard"):

Запуск восстановления данных

Перейдем в раздел "Восстановление" ("Restore") на вкладку "Восстановить на клиент" ("Restore multiple files"). В поле "Клиент" ("Client") выберем значение "bareos-fd". В поле "Задания резервного копирования " ("Backup jobs") выберем желаемую точку восстановления. В поле "Объединить все наборы файлов клиента" ("Merge all clients filesets") выберем значение "Нет" ("No"). В поле "Папка восстановления на клиенте" ("Restore location on client") укажем куда восстановить данные ("D:/test_restore") и запустим восстановление, нажав "Restore".

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

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

Ну что, наливаем чаек, сейчас мы будем расследовать - Детектив с Кластером Hyper-V

Дисклеймер: я привожу пример того, как я анализирую логи. Жесткого стандарта нет, и действия других инженеров техподдержки Veeam могут (и будут) отличаться. Скриншоты и логи взяты из моей лабы, так как логи клиентов никогда не публикуются и удаляются при закрытии кейса.

0. По традиции - все начиналось с ошибки.

Как и в любом детективе, начало весьма обычное: есть конкретная проблема. В этом случае выглядела она как тикет от клиента с примерно таким содержанием:"Помогите! Задание падает с ошибкой - Processing FS2 Error: Failed to get VM (ID: 6fb62d8a-4612-4106-a8e7-8030de27119e) config path. [WMI] Empty result."

Когда есть конкретная ошибка, это уже хорошо. Сразу понятно: что-то явно сломано это как стук в двигателе машины. Мы видим, что это ошибка в работе Backup job - задании резервного копирования для нескольких виртуальных машин. В этой ошибке даже есть аббревиатура [WMI], а это уже зацепка!

Как говорит википедия: WMI это одна из базовых технологий для централизованного управления и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows.А я бы сказал: WMI - это технология, используя которую Veeam B&R отправляет запросы на Hyper-V хост или кластер. Это могут быть такие запросы, как создание чекпоинта, удаление чекпоинта, создание коллекции, добавление VM в коллекцию и так далее.

Зная это, мы понимаем, что имеем дело с Hyper-V инфраструктурой. (Далее надо будет понять, кластер это или же одна нода). А проблема связана с WMI запросом, который вернул пустое значение. (Empty result)

Промежуточный вывод: задание резервного копирования для пяти виртуальных машин на гипервизоре Hyper-V завершилось успешно для трех машин, а для двух выдало ошибку - Failed to get VM (ID: 6fb62d8a-4612-4106-a8e7-8030de27119e) config path. [WMI] Empty result.

1. Приступаем к сбору логов

С чего же начинается анализ логов? - В первую очередь со сбора этих самых логов! В некоторых случаях собрать правильные логи - это уже полдела! Напоминаю, мы расследуем конкретное задание (Job), и портфель с логами нам нужен именно для этого задания.

Дело в том, что в задании помимо Veeam сервера задействованы другие компоненты. Это и Hyper-V ноды, на которых крутятся машины из задания, и репозиторий, на который пишутся файлы бэкапа, и прочие прокси. В общем случае таких серверов может быть достаточно много.И что же теперь? Нам лазать по всем серверам и копировать файлы? Нет, в нашей ситуации процесс сбора логов - полуавтоматический, благо в VBR есть встроенный помощник для таких дел. Есть даже статья с анимацией - https://www.veeam.com/kb1832 Поэтому, в консоли Veeam переходим в Menu -> Help -> Support information

При выборе опции (Export logs for this job), Veeam B&R соберет файлы со всех компонентов (прокси = Hyper-V ноды), вовлеченных в задание. Также будет добавлен HTML отчет, который может очень сильно упростить анализ. Одним словом - песня, все логи в одном архиве, да ещё и отчетик прилагается.

2. Анализ собранной информации

Итак, распаковали архив и видим следующее:

• Папка с логами, собранными с Veeam B&R сервера - storepc.dom1.loc

• Папки с логами, собранными с двух Hyper-V нод - 19node1 и 19node2

• Отчет по конкретному заданию - Critical FServers.html

Хммм, с чего же начать..

А начинать, я считаю, надо от общего к частному. Общим в нашем случае будет HTML отчет - так как в нем мы видим общую информацию о выполнении задания за период времени, и можно прикинуть статистику. Ну и, конечно же, отчет более приятен человеческому глазу, чем сотни строк логов =)

2.1 Отчет задания, и зачем его смотреть

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

Что же мы видим в отчете?

1. Сервер FS4 падает с ошибкой;

2. Через несколько минут - успешный Retry для сервера FS4

3. Во время следующего штатного выполнения задания серверы FS2 и FS3 падают с этой же WMI-ошибкой

4. Через несколько минут - успешный Retry для серверов FS2 и FS3

Вывод по анализу отчета: Из нашего списка машин при штатном выполнении задания некоторые падают, но обязательно отрабатывают с ретрая буквально через несколько минут. Установить закономерность падения машин невозможно, они падают рандомно. Также бывают абсолютно успешные штатные выполнения задания для всех машин.

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

Теории о том, что:

• есть проблемная машина или ряд проблемных машин;

• есть проблемная Hyper-V нода ;

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

2.2 Логи задания: ищем стэк ошибки

Так как ошибка одна, но появляется для разных машин, то мы просто выбираем любое выполнение задания с ошибкой и анализируем его. Для начала идем в лог, который описывает обработку конкретной машины в задании - той, для которой вышла ошибка. Схема, по которой ищутся логи для задания - Veeam сервер\Backup\Название задания. В нашем случае это storepc.dom1.loc\Backup\Critical_FServers. Более подробно про структуру логов и где что лежит мы писали в отдельных статьях здесь и здесь.

В этой папке для задания резервного копирования можно встретить 3 типа логов:

1. Agent - логи компонента, который занимается передачей данных (Veeam Agent - Data mover). Если в названии есть слово Target, значит - это лог агента, который записывал данные на репозиторий. Если это задание репликации, то Target будет в папке на сервере, который использовался в качестве целевого прокси и писал данные на хранилище данных гипервизора (Datastore) куда реплицируем. Если в названии есть слово Source, значит - это лог агента, который читал данные с хранилища данных гипервизора (Datastore).

2. Job - это лог задания целиком. При общении с сапортом можно смело говорить просто джоба, и вас поймут.

3. Task - это лог подзадания (таски), из которого состоит задание (Job). Каждая виртуальная машина в задании обрабатывается отдельной таской, которая пишет свой отдельный лог.

Мы открываем файл, начинающийся с Task и содержащий название VM. В нем просто ищем ошибку. Обычно нажимаем CTRL+End - это перебрасывает нас в самый низ лога, и потом крутим колесико вверх, пока не увидим нужную нам ошибку.

[29.09.2020 08:04:21] <38> Info     [WmiProxy:19node1] HviGetVmConfigPath: <InputArguments><Hvi_LogName value="Critical_FServers\HvWmiProxy-STOREPC-19node1.log" /><Hvi_Host value="STOREPC-19node1" /><Hvi_Process value="00002870" /><Hvi_RequestId value="000000000000002d" /><Hvi_TimeoutMs value="3600000" /><VmId value="3564c574-8a83-42d2-aef4-46e7218d8ccc" /></InputArguments>[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 17[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 16[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 15[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 14[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 13[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 12[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 11[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 10[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 9[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 8[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 7[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 6[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 5[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 4[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 3[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 2[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CProxyRpcInvoker} object [03dd98cb]: Counter = 1[29.09.2020 08:04:21] <42> Info     MRCReference: Release {CVeeamHvIntegrator} object [02ca5f28]: Counter = 1[29.09.2020 08:04:21] <42> Error    Failed to get VM (ID: 3564c574-8a83-42d2-aef4-46e7218d8ccc) config path. [WMI] Empty result. (Veeam.Backup.ProxyProvider.CHvWmiProxyErrorException)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.ProxyProvider.CHvWmiReconnectableRemoteCommand.InvokeInThread(Delegate dlg, Object[] args)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.ProxyProvider.CHvWmiReconnectableRemoteCommand.DoInvoke(CHvWmiProxyRequestContextNdw context, Int32 reconnectsCount, Delegate dlg, Object[] args)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.ProxyProvider.CHvWmiReconnectableRemoteCommand.Invoke[Ret](CHvWmiProxyRequestContextNdw context, Func`1 dlg)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.ProxyProvider.CHvWmiVmRemoteManager2015.GetConfigPath(Guid vmID)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.Core.HyperV.CHvVmSource2015..ctor(IVmBackupTask task, CBackupTaskSession taskSession, CBackup backup, CSmbLookupCache smbLookupCache, CHvSnapshotHolder snapshotHolder, CHvVssConnectionCreatorSet vssConnCreatorSet, IStopSessionSync sessionControl)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.Core.HyperV.CHvBackupJobPerformer.CreateSource(CHvVmTask task, CBackupTaskSession taskSess)[29.09.2020 08:04:21] <42> Error       at Veeam.Backup.Core.HyperV.CHvBackupJobPerformer.ExecuteTask(CHvVmTask task)

Стэк выглядит вот так, и нам он говорит, что был WMI запрос HviGetVmConfigPath: - этот запрос попытался получить путь до конфигурации VM по ID и в ответ получил пустой результат. Круто! Запрос! А дальше-то что?

А дальше нужно смотреть логи компонента, отвечающего за запросы, анализировать их, чтобы наконец построить теорию.

2.3 Логи WMI запросов на Hyper-V ноду с сервера Veeam

Нам нужны логи Veeam компонента, который отправляет WMI запросы на Hyper-V ноде.

Подсказка: его мы видим в стеке с ошибкой который я показал выше :

Host value="STOREPC-19node1"LogName value="Critical_FServers\HvWmiProxy-STOREPC-19node1.log

Идем в папку, собранную с интересующей нас Hyper-V ноды 19node1

И находим лог компонента, отвечающего за WMI запросы - HvWmiProxy. Ошибиться сложно, поскольку файл начинается с HvWmiProxy и заканчивается либо названием ноды, либо кластера (когда запросы отправляются в кластер). В нашем случае это название ноды - HvWmiProxy-STOREPC-19node1.log

Здесь мы находим уже весь запрос:SELECT Name, ElementName, __RELPATH FROM Msvm_ComputerSystem WHERE Name = "6fb62d8a-4612-4106-a8e7-8030de27119e"

И тут мы можем видеть, что он вернул пустой результат (Empty result). А что вообще он должен возвращать-то? Вопрос хороший, давайте посмотрим, как отработал успешный запрос для другой машины.

[29.09.2020 08:08:53.995] <  7748> hwp| HviGetVmConfigPath[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_CommitedRequestId__ARRAY = { 00001f0000000012, 00001f0000000011, 00001f0000000010 }[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_DevelopMode = True[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_Host = STOREPC-19node1[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_LogName = Critical_FServers\HvWmiProxy-STOREPC-19node1.log[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_Process = 00002440[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_RequestId = 00001f0000000013[29.09.2020 08:08:53.995] <  7748> hwp|   Hvi_TimeoutMs = 3600000[29.09.2020 08:08:53.995] <  7748> hwp|   VmId = da624636-429f-4bc9-b15e-a3de0bc77222[29.09.2020 08:08:53.995] <  7748> hwp| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[29.09.2020 08:08:53.995] <  7748> hwp| Getting VM (ID: da624636-429f-4bc9-b15e-a3de0bc77222) config path.[29.09.2020 08:08:53.995] <  7748> hwp| Executing wmi query 'SELECT Name, ElementName, __RELPATH FROM Msvm_ComputerSystem WHERE Name = "da624636-429f-4bc9-b15e-a3de0bc77222"'.[29.09.2020 08:08:54.003] <  7748> hwp| Executing wmi query 'associators of {Msvm_ComputerSystem.CreationClassName="Msvm_ComputerSystem",Name="DA624636-429F-4BC9-B15E-A3DE0BC77222"} where resultClass = Msvm_VirtualSystemSettingData'.[29.09.2020 08:08:54.179] <  7748> hwp| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[29.09.2020 08:08:54.179] <  7748> hwp| Result[29.09.2020 08:08:54.179] <  7748> hwp|   Hvi_RequestId = 00001f0000000013[29.09.2020 08:08:54.179] <  7748> hwp|   Hvi_State = Succeeded[29.09.2020 08:08:54.179] <  7748> hwp|   VmConfigFile = Virtual Machines\DA624636-429F-4BC9-B15E-A3DE0BC77222.VMCX[29.09.2020 08:08:54.179] <  7748> hwp|   VmConfigFolder = C:\ClusterStorage\Volume1\FSes\FS1[29.09.2020 08:08:54.179] <  7748> hwp| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[29.09.2020 08:08:54.179] <  7748> hwp| Duration: 0.184000 sec[29.09.2020 08:08:54.193] <  7912> hwp| ---------------------------------------------------------------------------

Видим, что результатом запроса был конфигурационный файл виртуальной машины. Возникает вопрос: почему же для одной машины файл был успешно найден, а для другой нет? Мы знаем, что через несколько минут на ретрае проблемная машина была все же обработана. Идем анализировать ретрай. (смотрим лог подзадания Task):

[29.09.2020 08:06:41] <23> Info     [WmiProxy:19node2] HviGetVmInfo: <InputArguments><Hvi_CommitedRequestId__ARRAY><value Val="0000000000000004" /></Hvi_CommitedRequestId__ARRAY><Hvi_LogName value="Critical_FServers\HvWmiProxy-STOREPC-19node2.log" /><Hvi_Host value="STOREPC-19node2" /><Hvi_Process value="00001d98" /><Hvi_RequestId value="0000000000000005" /><Hvi_TimeoutMs value="3600000" /><VmId value="3564c574-8a83-42d2-aef4-46e7218d8ccc" /></InputArguments>

Мы видим, что в этот раз запрос на получение конфигурационного файла машины уже шёл через другую Hyper-V ноду 19node2. Открываем лог HvWmiProxy со второй Hyper-V ноды и видим, что там WMI запрос отработал успешно.

Здесь я предлагаю сделать перерыв, не торопиться читать дальше, а попытаться самому построить теорию. Ведь в детективах самое интересное - это не просто дочитать до конца, а пытаться разгадать еще в середине, а потом просто проверить свои догадки.

2.4 Промежуточные итоги и наконец - теория!

Подводим промежуточные итоги анализа:

• Запрос валится с пустым значением, когда выполняется на одной Hyper-V ноде, и через несколько минут отрабатывает корректно, когда выполняется на другой Hyper-V ноде.

Напрашивается резонный вопрос почему на ретрае запрос стал выполняться на второй Hyper-V ноде? Как Veeam определяет, какая нода должна обрабатывать машину? Для обработки машины (создание снапшота и тд.) Veeam выбирает ту ноду, на которой находится машина (owner). В один момент времени у машины может быть только один владелец (owner). Получается, что в момент штатного выполнения машина числилась на одной ноде, а в момент ретрая уже на другой.

А такое вообще возможно?

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

Эту теорию о миграции надо проверять.

2.5 Проверка теории

Идем смотреть лог самого задания, он же Job лог. Там находим таблицу, в которой прописан список Tasks (подзаданий) для каждой машины:

[29.09.2020 08:03:16] <01> Info     Valid vm tasks ('5'):[29.09.2020 08:03:16] <01> Info     =================================================================================================================[29.09.2020 08:03:16] <01> Info     VM                   | Clust. |  Host                     | Size        | Provisioned |  Snapshot Mode| Off-host proxies                                  [29.09.2020 08:03:16] <01> Info     =================================================================================================================[29.09.2020 08:03:16] <01> Info     FS1                  | yes    |  19node1                  | 1024 MB     | 4 MB        |        enCrash|                                                   [29.09.2020 08:03:16] <01> Info     FS2                  | yes    |  19node1                  | 1024 MB     | 4 MB        |        enCrash|                                                   [29.09.2020 08:03:16] <01> Info     FS3                  | yes    |  19node1                  | 1024 MB     | 4 MB        |        enCrash|                                                   [29.09.2020 08:03:16] <01> Info     FS4                  | yes    |  19node1                  | 1024 MB     | 4 MB        |        enCrash|                                                   [29.09.2020 08:03:16] <01> Info     FS5                  | yes    |  19node2                  | 1024 MB     | 4 MB        |        enCrash|     

В таблице ясно виднона какой ноде находилась VM во время начала задания. Здесь мы видим, что FS4 была на первой ноде. Смотрим таблицу во время ретрая:

Lifehack: переключаться между выполнениями задания в логе (и штатными, и ретраями) очень удобно, нажав CTRL+f (поиск) и искать new log. Таким образом будешь скакать от выполнения к выполнению - только не забудь указать, куда хочешь мотать, вперед или назад.

[29.09.2020 08:06:45] <01> Info     Valid vm tasks ('1'):[29.09.2020 08:06:45] <01> Info     =================================================================================================================[29.09.2020 08:06:45] <01> Info     VM                   | Clust. |  Host                     | Size        | Provisioned |  Snapshot Mode| Off-host proxies                                  [29.09.2020 08:06:45] <01> Info     =================================================================================================================[29.09.2020 08:06:45] <01> Info     FS4                  | yes    |  19node2                  | 1024 MB     | 4 MB        |        enCrash|   

Вуа-ля! Мы подтвердили, что машина мигрировала (смена ноды для машины и есть миграция).В случае необходимости можно запросить и глянуть Windows Events с ноды. Нужные события находятся в ветке Hyper-V-VMMS > Admin.

Элементарно, Ватсон!

Следовательно, такую, казалось бы, мистическую ситуацию можно объяснить достаточно просто во время начала задания Veeam строит список машин, которые нужно будет обработать, и определяет на какой Hyper-V ноде какая машина находится. Когда дело доходит до машины, то обрабатывается именно та Hyper-V нода, на которой она была в момент начала задания.

В ситуации, когда в задании много машин, и некоторые ждут своей очереди несколько часов, вполне реальна ситуация, что машина мигрирует на другую ноду, и возникнет такая ошибка. На ретрае Veeam опять определяет Hyper-V ноду для машины, и все отрабатывает штатно. Это одна из причин, почему десять мелких бекапных заданий будут лучше, чем одно большое.

Возникает законный вопрос почему бы не определять Hyper-V ноду для машины прямо перед началом её обработки, чтобы учесть возможность миграции? Дело в том, что такие ограничения связаны с шаренными снапшотами и оптимизациями для параллельной обработки виртуальных машин.

Шаренный снапшот - это когда создается теневая копия на уровне хоста, и в неё добавляются сразу несколько компонентов Hyper-V VSS райтера. Это необходимо, чтобы сделать одну теневую копию волюма, и с этой копии сделать бэкап нескольких виртуальных машин, расположенных на нем. В противном случае для каждой виртуальной машины будет создаваться заново теневая копия всего волюма, на котором расположено несколько машин.

Эти настройки описаны здесь - https://helpcenter.veeam.com/docs/backup/hyperv/backup_job_advanced_hv_hv.html?ver=100

Подробнее о том, зачем используется теневая копия (VSS) во время бэкапа, можно почитать здесь - https://helpcenter.veeam.com/docs/backup/hyperv/online_backup.html?ver=100#2012r2

А сама опция называется - Allow processing of multiple VMs with a single volume snapshot

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

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

Автор: Никита Шашков (Veeam), Customer Support Engineer.

Снятие снапшота - именно с этого начинается любой бекап. До тех пор, пока мы не знаем, как сбросить все буфера на диск и привести файлы с данными в консистентное состояние, мы не бекапы делаем, а занимаемся копированием файлов с непредсказуемым содержимым внутри. Понимая важность снапшотов, все вендоры стараются дать нам если не полностью готовую функцию (типа Time Mashine в MacOS), то хотя бы набор ручек, за которые можно подёргать (вроде модуля dm-snap в ядре Linux).

Но сегодня речь пойдёт про самую распространённую ОС - Microsoft Windows, где эта задача решается с помощью Volume Shadow Copy сервиса, известного в народе под аббревиатурой VSS (Volume Snapshot Service). А нашего внимания он удостоился из-за того, что, несмотря на всю популярность своего материнского корабля, сам он окутан вуалью из тайн и мистических слухов. Давайте уже как-то разберёмся с этой штукой.

А, собственно, что с ним за проблема? Вот есть документация, где вполне адекватно и красиво описано, как всё работает. Есть утилита vssadmin, позволяющая вполне годно создавать и удалять снапшоты. Что не так-то, и где сложности?

Но проблема в том, что более лучшая документация, намного правильнее отражающая происходящие процессы, несколько сложна для понимания. Microsoft вообще написал по этой теме какое-то неслыханное количество документов. Но даже когда вам как-то удаётся выстроить в голове работу этого алгоритма, вы сразу сталкиваетесь с тем, что на практике многие вещи работают совершенно не так, как описаны. Или вообще не работают. А что-то не описано совсем, хотя этому мы уже давно не удивляемся. Но не хвататься же сразу за дебагер и дизассемблер, да?

Хотя упомянутый выше vssadmin как-то вроде и работает, и снапшоты даже делает, и вообще молодец. Но это всё до того момента, пока ты не начинаешь вникать в тонкости, где может выясниться, что репорт об успешно созданном снапшоте - это репорт о чём угодно, только не об успешно созданном снапшоте.

Вот поэтому и захотелось немного поговорить о том, как же на самом деле работает VSS. И да, строго говоря, результатом работы VSS является созданная shadow copy. Но дабы не ломать язык и не мучить вас транслитом, давайте просто писать снапшот.

Какова роль VSS

Не сомневаюсь, что 90% читающих прекрасно понимают, зачем нужны снапшоты, но ради оставшихся 10% потерпите несколько предложений. Или сразу идите в следующий раздел.

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

Сами снапшоты ничего не знают про ваши файлы и папки. Они работают на уровень ниже файловой системы - с блочными устройствами и блоками данных. Если придерживаться терминологи Microsoft, то снапшот - это место, именуемое Shadow Storage, куда записываются изменённые блоки данных и откуда их можно извлекать с целью переписать данные на оригинальном диске. Тут можно запомнить для себя два нюанса. Первый - только что сделанный спапшот занимает ровно ноль байт. Это просто пре-алоцированное место, куда файловая система может копировать измененные блоки (или наоборот, новые блоки, но не суть). И второй - теневая копия суть есть дифференциальный бекап. Все данные, которые вы изменили, не удаляются, а отправляются на хранение в этой зоне.

Где найти VSS

Обнаружить следы VSS можно двумя классическими способами: через GUI или в консоли. В зависимости от конкретной версии системы пути могут немного отличаться, но суть будет одинакова. Итак, есть у меня в лабе Windows Server 2019, и если сделать ПКМ на любом диске в проводнике, мы увидим два пункта: Configure Shadow Copies и Restore previous versions.

Если зайти в мастер настроек, то можно включить создание теневых копий для любого диска, задать расписание, по которому они будут создаваться и, что самое интересное, указать место хранения этих копий. Строго говоря, даже не самих копий, а так называемой diff area - места, куда сбрасываются перезаписанные на оригинальном томе сектора. То есть мы запускаем создание снапшота одного диска, а его данные физически храним на другом. Функция архиполезная и позволяет не просто снижать нагрузку на конкретном диске, но и делать фокусы а-ля снимаем снапшот одной ноды в кластере и цепляем его к другой.

После того,как вы всё настроите на свой вкус, появляется смысл в пункте Restore previous versions. Чисто технически туда и до этого можно было зайти, однако внутри, скорее всего, будет только гнетущая пустота.

Но всё это баловство с графическим интерфейсом, и как мы знаем, до добра это не доводит, поэтому открываем powershell (или даже cmd, почему нет) - и там у нас имеется два варианта из коробки: vssadmin и diskshadow. Первая утилита есть практически на любой системе, начиная с WinXP/Win2003. Нет её только на Windows 8. По какой-то таинственной причине из восьмёрки вырезали инструменты управления теневыми копиями, но потом осознали свою неправоту и вернули всё на место. А вот diskshadow доступен только на серверных вариантах Windows. Это уже более продвинутый вариант vssadmin, позволяющий работать не только в интерактивном режиме, но и выполнять целые скрипты, написанные на понятном этому интерпретатору языке. Да и просто это более адекватный и поддающийся контролю инструмент.

И запоминаем самое важное: это две разные утилиты, существующие в разных контекстах. Теневая копия, сделанная в одной утилите, будет видна другой, однако статус у неё будет неоперабельный.

Технически ничего не мешает одновременно делать снимки с помощью vssadmin и diskshadow. Хотя есть вероятность, что получите сообщение типа Another shadow copy is in progress. Но это так, к слову пришлось. Не надо пытаться одновременно делать несколько снапшотов разными программами.

Как появился VSS

Итак, судя по написанному выше, всё просто: нам надо просто брать появляющиеся блоки и сохранять их куда-то в сторонку, чтобы при необходимости вынимать обратно. Сразу возникает первый вопрос: а что именно надо сохранять в нашем теневом хранилище? Ведь действительно, можно просто писать в него все приходящие новые блоки и сохранять в метаданные, на какое место они (блоки) должны были быть записаны. А можно поступить чуть сложнее и записывать новые блоки сразу на полагающееся им место, а в хранилище отправлять содержимое перезаписываемых блоков. Что лучше и как выбрать? На самом деле право на жизнь имеют оба варианта, и какой выбрать - зависит исключительно от воли вендора. Первый подход (redirect-on-write, RoW, если оперировать грамотными терминами) быстро пишется, но долго читается. Зато если надо откатиться на первоначальное состояние, это делается моментально - мы просто удаляем наше теневое хранилище. Второй подход (copy-on-write, CoW) пишется медленней, читается быстрее и моментально удаляет копии предыдущих состояний. VSS, к слову, придерживается парадигмы CoW, а в снапшотах VMware реализован RoW.

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

Давайте рассмотрим хрестоматийную ситуацию с файлом базы данных. (И если у вас уже заскрипел песок на зубах, смело пропускайте следующие два абзаца.) Итак: у нас есть банальная SQL Server база данных в виде mdf файла, и тут к нам прилетает какой-то запрос. SQL, как порядочное приложение, начинает старательно вносить изменения в файл, а мы старательно перехватываем каждый новый блок данных падающих на диск и пишем в нашу теневую копию. Всё хорошо и здорово, но тут выключили свет. Потом свет включили, сервер запустили и мы даже базу восстановили из нашей теневой копии, но тут оказывается, что SQL не запускается. Говорит - база в не консистентном состоянии. Это значит следующее: во время нормальной работы завершение каждой транзакции помечается специальным флагом. Сервер его видит и знает, что всё хорошо. А тут сервер загружается, видит, что из его базы торчит какой-то кусок данных, флага нет и, следовательно, что с этим всем делать - он понятия не имеет. То ли удалить, то ли дописать, то ли ещё что-то. Но у нас тут не угадайка, а всё должно быть однозначно и консистентно. Поэтому он принимает решение выключиться, дабы не поломать базу ещё сильнее.

Хорошо, но как избежать подобных приключений? Отличным вариантом будет подождать, пока SQL сервер допишет свою транзакцию, пометит её как завершённую, и потом мы быстренько заберём все появившиеся новые блоки. Отличный вариант, который надо срочно реализовывать! Вот только есть небольшая проблема: до этого мы говорили про одно приложение и один файл, с которым оно работает. Научиться общаться с условным SQL Server много ума не надо, но что делать с остальными миллиардами существующих приложений? А что делать, в конце концов, с самой ОС, у которой внутри огромное количество своих процессов и открытых файлов? Вот примерно с такими проблемами и столкнулись учёные мужи из Microsoft, когда пришли к выводу, что надо реализовать некий общий интерфейс, через который можно будет сразу всем прокричать нечто вроде: Сейчас мы будем делать снапшот, так что быстренько сворачиваемся и сбрасываем буфера на диск! Приостанавливайте свою кипучую деятельность и приводите данные в консистентный вид!. Ну а назвать эту штуку они решили, как вы уже догадались, Volume Snapshot Service. Или просто VSS.

И тут можно воскликнуть - но ведь в Windows 2008 был представлен Kernel Transaction Manager! Это разве не то же самое? Он же как раз занимается тем, что приводит файлы на диске в консистентное состояние. А вот и нет! То есть да, KTM приводит, но отвечает только за дисковые операции, а что там происходит с приложениями - его мало волнует. А ведь многим из этих приложений важна не просто целостность файлов, но и что в них записано. Классический пример - это Exchange и Active Directory. И тут мы подошли к важной теме:

Как устроен VSS

Чтобы не прыгать с места в карьер громады страшных терминов и процессов, начнём с высокоуровневого описания. Поэтому ограничимся таким списком компонентов:

• VSS Writer. В кириллическом простонародье известен как просто райтер, поэтому так и будем его называть в дальнейшем, вызывая праведный гнев ненавистников англицизмов.

  Райтер занимается тем, что выстраивает мостик взаимодействия между VSS подсистемой и конкретным приложением. Поэтому а) в любой системе их будет достаточно много (проверьте у себя с помощью vssadmin list writers) б) райтер всегда пишется поставщиком приложения, ибо кроме него никто не знает, что там и как должно происходить во время создания снапшота.

  Соответственно, райтер по своей сути выполняет роль регулировщика: сначала он говорит приложению подготовиться к снапшоту, затем даёт отмашку VSS сервису делать снапшот. Или не даёт, если приложение не смогло за установленный промежуток времени подготовить свои файлы.

  Также хочется отметить, что райтеры - это какие-то невероятно нежные ребята, которые зачастую ломаются без каких-либо внешних признаков. Поэтому если в выводе vssadmin list writers в поле State вы увидите что-то, отличающееся от Stable, это надо чинить, ибо сделать консистентный бекап, увы, не получится.

• VSS Provider. Тот самый парень, который занимается созданием и управлением снапшотами. Известен тем, что бывает софтовый или хардовый. Список установленных в системе провайдеров можно посмотреть с помощью команды vssadmin lisrt providers. По дефолту, с системой идет Microsoft Software Shadow Copy provider. Он даже отлично и замечательно работает, но до тех пор, пока вы не подключите к системе брендовую СХД. Хорошие вендоры всегда снабжают свои железки управляющим софтом, в составе которого находится и родной провайдер к этой железяке. Благодаря этому можно уже делать всякие хитрые трюки, которые реализованы в вашем оборудовании, и именно поэтому мы в Veeam так гордимся списком интеграций с железом.

• VSS Requestor. Участник процесса, который инициирует создание VSS снапшота или восстановление данных. Можно сказать, что реквестор - это бекапное приложение, которое общается с райтерами и провайдерами. Может показаться, что его роль незначительна, однако от грамотности реализации реквестора зависит качество получаемого результата. То есть VSS не будет за вас думать, что и в каком виде надо сделать. Чем более чёткие инструкции выдаст реквестор, тем более предсказуемым будет результат.

Как в итоге всё выглядит на самом высоком уровне: реквестор стучится в Volume Shadow Copy сервис, тот отдаёт команду райтерам предупредить приложения о надвигающемся снапшоте, райтеры рапортуют об успехе, а сервис отдаёт команду провайдерам делать снапшоты. О результатах докладывается реквестору.

Но на деле, очевидно, всё несколько сложнее. На первом шаге реквестор проверяет, что вообще есть в наличии и с кем предстоит общаться. Затем после составления списка райтеров он обращается к провайдеру, объясняя, что он хочет заснапшотить и где должен располагаться снапшот. Это называется SnapshotSet. В большинстве случаев он будет располагаться на том же вольюме, что и оригинальный диск. А меньшинство случаев - это те самые хардварные провайдеры, которые поставляются вместе с СХД. Для них нормой считается создавать отдельный вольюм для снапшота, который называется storage snapshot. А в определённых случаях можно так и вообще перемещать снапшот на другое физическое устройство, чтобы выкачивать данные уже оттуда, а не с прода. Без хардварных провайдеров сделать такое не выйдет.

Следом начинается стадия, именуемая Prepare for backup. На этом этапе мы должны уже не просто изучить метаданные райтеров, а запросить их реальные статусы и приготовиться к самой жаркой поре: все райтеры должы будут отработать один за другим. Причём каждый должен уложиться в отведённое ему время, которое по умолчанию равно 60 секундам. Так решили в Microsoft, забыв уточнить причины. Но есть ещё приложения-чемпионы, например, Exchange. Его авторы посчитали, что 20 секунд более чем достаточно, и остановились на таком лимите. А чем чревато невыполнение этого этапа, который в документации называется OnFreeze? Тем, что райтер вернёт сообщение об ошибке, и снапшот не будет сделан. После чего в интерфейсе Veeam появится одна из каноничных ошибок вроде VSSControl: Failed to freeze guest, wait timeout". Тут радует одно: в логах VSS всегда будет написано, какой именно райтер завалил задание. А по самим ошибкам уже столько KB написано, что вспоминать страшно. Но если вы вдруг сомневаетесь, то точно вам говорю - написанному в них можно смело верить. И если после всего получается, что у вас слишком медленное хранилище, и за отведённое время не получается сбросить все кэши на диск, ну, значит, так оно и есть. Физику не обманешь, а вот железо надо хоть иногда обновлять.

Но это был пессимистичный вариант (прошу понять меня правильно, но беды с VSS - это очень частная причина обращений в сапорт), а в оптимистичном можно начинать самый важный этап. Как только райтеры рапортуют, что всё, вся деятельность в системе заморожена, а кеши сброшены на диск, у нас есть десять(!!!) секунд на создание снапшота, после чего райтеры будут принудительно разморожены, и всё закрутится вновь. И можно сказать, что на этом процесс бекапа заканчивается, и всё что нужно - это просто импортировать наш снапшот и скачать его куда-то к себе, чтобы сохранить под семью замками. Однако есть одно важное Но - log truncate. Фундаментально это вообще не связанные операции и транкейт зависит только от бекапа логов, но как все мы понимаем - на пользовательском уровне эти вещи связаны в единый процесс. То есть, прежде чем выкачивать снапшот, надо не забыть выдать команду backup log, которая запустит операцию транкейта. И после этого совесть наша чиста.

Но что дальше происходит с данными? Если мы действительно используем какое-то приложение для бекапов, которое запустило весь этот процесс, дождалось его завершения и скачало данные в своё хранилище, то снимок можно просто удалить одной командой. Поскольку VSS пропагандирует CoW подход, то речь здесь действительно о банальном удалении нашей аллоцированной зоны, ведь все новые данные сразу пишутся на оригинальный диск. Это называется non-persistent shadow copy, и она не имеет никакого смысла без оригинального диска.

Чтобы пройти этот путь вручную, достаточно открыть консоль и набрать:

PS C:\Windows\system32> diskshadowMicrosoft DiskShadow version 1.0Copyright (C) 2013 Microsoft CorporationOn computer:  VEEAM,  17.05.2021 19:18:44DISKSHADOW> add volume c: # добавляем в задание диск СDISKSHADOW> create# создаём снапшотAlias VSS_SHADOW_1 for shadow ID {a1eef71e-247e-4580-99bc-ee62c42221d6} set as environment variable.Alias VSS_SHADOW_SET for shadow set ID {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c} set as environment variable.Querying all shadow copies with the shadow copy set ID {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c}        * Shadow copy ID = {a1eef71e-247e-4580-99bc-ee62c42221d6}               %VSS_SHADOW_1%                - Shadow copy set: {cc9fab4d-3e7d-44a5-9a4d-0df11dd7219c}       %VSS_SHADOW_SET%                - Original count of shadow copies = 1                - Original volume name: \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ [C:\]                - Creation time: 17.05.2021 19:19:45                - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2                - Originating machine: veeam.university.veeam.local                - Service machine: veeam.university.veeam.local                - Not exposed                - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}                - Attributes:  Auto_Release DifferentialNumber of shadow copies listed: 1

Здесь мы видим, что успешно создался снапшот со своим Shadow copy ID, и для удобства ему сразу присвоили алиас VSS_SHADOW_1. Этими данными вполне можно оперировать, если возникает такое желание. Однако не будем уходить в сторону и попробуем прочитать содержимое этого снимка. Для чего подмонтируем его в качестве диска.

DISKSHADOW> expose {a1eef71e-247e-4580-99bc-ee62c42221d6} Z:The shadow copy is a non-persistent shadow copy. Only persistent shadow copies can be exposed.

Однако на такое, казалось бы, простое и законное желание мы получили не менее законный отлуп, ибо сделали non-persistent снимок, а, значит, единственное, на что он годится - это записать его поверх родного, удалив на нём всю информацию, которая появилась после создания этого снимка. Но такая история нас не устраивает, поэтому стираем всё безжалостно.

DISKSHADOW> delete shadows all # или только нужный IDDeleting shadow copy {a1eef71e-247e-4580-99bc-ee62c42221d6} on volume \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ from provider {b5946137-7b9f-4925-af80-51abd60b20d5} [Attributes: 0x00420000]...Number of shadow copies deleted: 1

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

DISKSHADOW> add volume C:DISKSHADOW> set context persistent # вот этот моментDISKSHADOW> createAlias VSS_SHADOW_1 for shadow ID {346d896b-8722-4c01-bf01-0f38b9abe20a} set as environment variable.Alias VSS_SHADOW_SET for shadow set ID {785983be-e09d-4d2a-b8b7-a4f722899896} set as environment variable.Querying all shadow copies with the shadow copy set ID {785983be-e09d-4d2a-b8b7-a4f722899896}        * Shadow copy ID = {346d896b-8722-4c01-bf01-0f38b9abe20a}               %VSS_SHADOW_1%                - Shadow copy set: {785983be-e09d-4d2a-b8b7-a4f722899896}       %VSS_SHADOW_SET%                - Original count of shadow copies = 1                - Original volume name: \\?\Volume{7fd0c79d-0000-0000-0000-602200000000}\ [C:\]                - Creation time: 17.05.2021 19:38:45                - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3                - Originating machine: veeam.university.veeam.local                - Service machine: veeam.university.veeam.local                - Not exposed                - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}                - Attributes:  No_Auto_Release Persistent DifferentialNumber of shadow copies listed: 1

Как мы видим: Attributes: No_Auto_Release Persistent Differential. Поэтому если теперь вы сделаете expose, то снапшот примаунтится как полноценный диск, по которому можно перемещаться и копировать с него файлы. Диск, само собой, виртуальный и состоит из блоков оригинального диска, плюс блоки изменившихся данных, читая которые, мы можем видеть состояние оригинального диска на момент снапшота. Всё просто.

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

Что тут хочется ещё сказать, а вернее, спросить: если всё так просто, то почему же я говорю, что всё так сложно? Проблема в том, что, отдавая на боевом сервере команду vssadmin create shadow, мы, конечно, создаём какой-то снимок, но как себя будут чувствовать приложения после отката на этот снимок, мы предсказать не можем. Это не шутка: команда create признаёт наличие ошибок при выполнении как вариант нормы. Райтер не вернул вовремя Ок от приложения? Да кому это надо, го делать снапшот, я создал.

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

Как лечить VSS

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

Другая проблема - это железо. Помните про временные рамки для райтеров? Про десять секунд на снапшот? Для многих это ограничение становится проблемой из-за того, что СХД физически не успевает сделать требуемые действия за отведённое время. Как это лечится? А вот никак. Или покупаем более мощное железо, или ищем пути снижения нагрузки, чтобы операция была проведена за выделенный промежуток времени.

Если посмотрите одно из самых популярных KB1680: VSS Timeout when backing up Exchange VM, то легко обнаружите, что первые три шага для решения всех проблем с VSS - сделайте снапшот вручную и посмотрите чтобы это заняло менее 20 секунд, перезагрузитесь и попробуйте снизить нагрузку. Вот так и живём, да.

И что же делать, если VSS падает, в ивентах ничего нет, а понять, что происходит надо? Тут я могу порекомендовать три хороших статьи:

• КВ от Veeam, посвящённое анализу поведения VSS с помощью diskshadow.

• Другое KB от Veeam, посвящённое сбору информации с помощью vsstrace из Windows SDK. Но скажу сразу, это уже не для слабых духом.

• И видео от моего коллеги, где он наглядно показывает, как работать с информацией из первых двух пунктов =) Рассказывает он действительно хорошо, но с непривычки голова у вас от объёма информации заболит, это я вам обещаю.

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

А на сегодня всё. Я и так хотел кратенько, но получилось больше десяти страниц текста. Поэтому самое время закругляться. Если хочется раскрытия какой-то другой темы или углубиться в детали VSS, то обязательно пишите об этом в комментариях.

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

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

Что за человек такой - инженер Technical Customer Support в Veeam Software?

В идеальном мире это тот самый универсальный человек, требования к которому сформулированы сухим кадровическим текстом в описании вакансии. И швец, и жнец, и на дуде игрец. Вот только есть одна небольшая проблема его не существует. Так что если вы не знали, то держите первое открытие за сегодняшний день: вакансии, как правило, пишутся под идеального кандидата в вакууме, которого никто никогда не видел. А если даже такой вдруг покажется на горизонте, то его с руками оторвут. Отсюда вывод: если вы не подходите под все пункты в описании вакансии, это нормально, и можно смело откликаться. Если только пропущенные пункты не помечены как критически важные. Тут уж действительно мимо.

Но вернёмся к нашему инженеру техподдержки в Veeam. И да, это наш блог, так что простите, но пишем мы про то как всё устроенно именно у нас, а не у соседей. Так вот, все его навыки можно объединить в три группы: это технические скилы, знание языка и умение общаться с клиентами. Сразу возникает вопрос: а что важнее? Можно же взять сисадмина и научить его разговорному английскому. Или выпускника филфака за недельку натаскать по книжкам а-ля VMware for Dummies. А самого последнего грубияна - отправить на курсы придворного этикета, где его научат родину любить и вилкой с ножом пользоваться, и с людьми вежливо общаться. Но вас тут ждёт большое разочарование: мы в Veeam ищем комбинацию всех трёх навыков в одном человеке. Любой и каждый желающий вступить в наши стройные ряды обязательно проходит все три этапа отбора. К нам трудно попасть, легко потерять и . ну вы и сами знаете.

На практике этапы отбора могут идти вразнобой, но давайте представим, что первым будет техническое собеседование. И как вы думаете, что же можно спросить у кандидата, если твои продукты - это корпоративный софт, и вероятность того, что кандидат их хотя бы видел, крайне мала? Про то, что он их использовал хотя бы в рамках домашней лаборатории, даже фантазировать не будем. Правильно, спросить можно всё что угодно, только не про сам софт. Поэтому техническое собеседование -- это разговор про IT-кругозор кандидата и имеющиеся у него навыки. Вся наша работа строится вокруг множества технологий. Среди них гипервизоры VMware и Hyper-V, Nutanix AHV, Azure, AWS, Oracle, SAP HANA и так далее. Но мы не ожидаем, что кандидаты знают их так же, как и мы. Нет, но если они могут хоть как-то поддержать разговор про виртуальные машины, то им сразу плюсик в карму, тут без сомнений. И мы не ожидаем, что они могут хотя бы час заливаться соловьём, сравнивая особенности работы корпоративных СХД. Или что готовы без запинки объяснить разницу между Ms SQL, MySQL, Oracle и Redis. Нет, ничего такого знать совершенно не требуется. Всему, что надо будет, проще потом научить, но вот базу кандидаты знать обязаны.

Что такое реестр в винде, зачем нужны виртуальные машины, почему домены водятся в лесу, как пинг связан с эхо, а шутка про udp может и вообще не дойти. Если хоть что-то из предыдущего предложения вызывает у кандидата затруднения, то у него нет этой самой базы. Если человек хотя бы улыбнулся в процессе чтения этих вопросов, то, похоже, в этой голове что-то есть. Ведь учиться читать, не зная букваря, сами понимаете, затея гиблая. Поэтому ещё раз: каких-то супер-узких знаний мы от кандидатов не ждём (но если они есть, мы будем только рады), но уверенные знания уровня молодого сисадмина быть должны строго обязательно.

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

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

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

Из всего вышесказанного вывод язык надо знать на разговорном уровне. Пусть и не идеально грамматически, пусть без RP-прононса, но наш инженер должен смело говорить Welcome, понимать, что ему говорят, и не запинаясь говорить в ответ. Это называется поддерживать диалог. По нашим наблюдениям, такие знания начинаются на уровне intermediate и есть практически у всех, кого стандартные языковые тесты оценивают как upper-intermediate. Но не переживайте, мы не доверяем оценку навыков бездушным тестам. Ведь основная задача любого теста - это проверить способность человека проходить этот тест, а не выявить его реальный уровень знаний. Поэтому основное заключение здесь дают наши внутренние преподаватели английского, проводящие интервью. И, надо признать, на этом этапе проваливается довольно много кандидатов. Но давайте будем честными сами с собой: без английского в наше увлекательное время в IT-индустрии приходится довольно туго.

И завершающим этапом служит так называемый customer care. Вещь пока малоизвестная по стране в целом, но очень важная для всех, кто работает с западными рынками. Заключается она не только в умении быть вежливым и красиво выходить из любой ситуации, но и в том, чтобы любить человека как класс. Чтобы даже самый лютый негативщик сиял от радости после общения с нашим специалистом. Тут ведь штука какая: к нам крайне редко звонят, чтобы просто сказать спасибо за наш супер-крутой софт и отличный сервис. Обычно на звонок людей побуждает наличие какой-то проблемы, которую надо решить здесь и сейчас. То есть звонящий априори раздражён, ему плохо, и он совершенно не против на ком-то сорваться. Возможно, даже поорать. И вот тут ваши навыки общения, умение оставаться вежливым и искреннее желание помочь человеку с его бедой выходят на первый план. И вы не поверите, но мы и этому всему научим, а на входном тестировании кандидатов интервьюируют люди, профессионально занимающиеся проблемами customer care. (Да, бывают и такие.)

Теперь соберём всё вместе. Идеальный (но несуществующий) кандидат - это сисадмин, развивший свои навыки дальше замены картриджей и переустановки винды. Он устал от типовых проблем у типовых юзеров и хочет расти как технический специалист. Поэтому он неплохо владеет английским на достаточном для поддержания осмысленной беседы уровне. А также способен проявлять чудеса выдержки при общении и неизменно вежлив.

А теперь зайдем с другой стороны

Чего ради такому замечательному специалисту идти работать к нам в техподдержку? Пусть даже в гордом звании инженера.

Ответ в самой сути работы. Вот, например, получил товарищ свой первый опыт в техподдержке провайдера. Чем он там занимался на первой линии? Сидел целый день с телефоном в обнимку, просил перезагрузить роутер по питанию и проверял достаточность денег на счету. Возможно, он даже перешёл с первой линии на вторую, и ему доверили десять простых команд на аксесных свичах. А по праздникам разрешили прописывать MAC-и и vLAN-ны.

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

И таких примеров масса. Слово техподдержка прочно ассоциируется с примитивными проблемами, надоедливыми пользователями, их пользовательскими проблемами и бесконечными попытками выбраться из этого болота.

А вот наши инженеры с пользователями (в обывательской трактовке термина пользователь) не работают. Совсем и никогда. Наши клиенты - это такие же сисадмины, как и они сами. Они не просят починить принтер, переключить монитор в соседнюю розетку и поменять обои - они содержат инфраструктуры, зачастую огромные и напичканные топовым железом, куда простых смертных на пушечный выстрел не подпускают. И наши инженеры техподдержки - не простые смертные. Они - профессионалы, в которых уверены мы сами и которым доверяют другие инженеры со всего света.

И вот вам первое же отличие: они и не сидят на телефоне целый день. Они набирают из очереди кейсов, отключаются от звонков и занимаются их решением. Потому что на первой же линии мы решаем до 80% обращений. А это, напомню, не истории про зависший роутер, а серьёзные инфраструктурные задачи такого уровня, который львиная доля его бывших коллег может себе только нафантазировать. И то, если наберётся достаточной смелости.

Почему мы так безапелляционно утверждаем, что инфраструктуры сложные, а задачи интересные? Здесь можно просто посмотреть на список наших клиентов и представить, что звонить будут инфраструктурщики крупнейших банков, гигантских международных корпораций и прочих компаний, про которые знает буквально каждый. А ведь мы им не корпоративы с бегом в мешках устраиваем, а решаем проблемы с инфраструктурой, в которой могут быть сотни, а то и тысячи элементов.

Youre in the army now

Ладно, предположим, что кандидат прошёл через горнило отбора, и мы все рады приветствовать нового члена нашей команды. Теперь уже коллеге выдали стол, стул, компьютер, чашку и прочие ништяки новичка, но что будет дальше?

А дальше его ждут три месяца интенсивного обучения. Причём с умным видом дремать на лекциях не получится можно считать, что это обучение без отрыва от производства, с учебными KPI. Где-то с середины программы постепенно начинается работа с кейсами. Поэтому к концу испытательного срока от новобранца ожидается где-то 30-40 закрытых кейсов и уже какие-то свидетельства того, что инженер может применить полученные знания на практике.

Само собой, первым делом ему выделят ментора и начнут подтягивать уровень технических знаний по всем необходимым нам областям. Это гипервизоры, сети, различные операционки, СУБД, СХД, облака и многое другое. Даже если он решит уволиться спустя эти три месяца, с таким набором знаний его с руками отрывают в любую купи-продай контору на должность старшего сисадмина. Но так скоропостижно увольняются только уверенно придерживающиеся методологии Сам Себе Злобный Буратино. Настоящий инженер уже почувствовал, что в IT-мире бывают интересные и нетривиальные задачи, за решение которых платят приятную зарплату, поэтому зачем опять идти торговать помидорами?

Ладно, вернёмся к обучению. Пока новичок будет старательно впитывать базовые инфраструктурные вещи, мы начнём учить его работе с нашими продуктами. Это отдельный пласт знаний, который, кстати говоря, весьма неплохо ценится на рынке труда даже сам по себе. И как только новичок научился ориентироваться в этом море информации, случится страшное он получает первый настоящий кейс. Вернее, он берёт его сам. Скорее всего, этот кейс будет предельно простенький, а за действиями нового инженера будет тщательно следить ментор, но всё будет хорошо. Следом будут простые звонки клиентам, когда надо что-то уточнить в их запросе, но рано или поздно он примет свой первый настоящий звонок, и уже никто не будет знать, с чем к нему обратятся на том конце провода. Возможно, просто уточнят что-то по настройкам, а возможно, там упал прод и надо срочно всё поднимать. Но бояться здесь нечего, так как всю дорогу на протяжении этих месяцев ментор будет наблюдать, подсказывать и при малейшем намеке на непонимание советовать, как лучше поступить. Ведь если у нас есть тренировочные кейсы, то тренировочных клиентов у нас нет. Они все настоящие, и права на ошибку мы не имеем.

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

Когда три первых месяца пройдут, новичок - уже не новичок, а полноценная боевая единица, которую можно смело выпускать для самостоятельного общения с клиентами. Но не стоит думать, что на этом его развитие и остановится. Вот ещё! Языковые курсы, лекции по новым технологиям, продуктам и всё, чтобы только лишь не отставать от семимильных шагов нашей бурной индустрии. Со временем, если инженер захочет углубить свои знания по конкретным вещам, у него будет возможность примкнуть к выделенным командам. Например, у нас есть отдельные команды, занимающиеся Linux, облаками, сервис-провайдерами, и так далее. Словом, возможностей развития хоть отбавляй.

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

Итого

Инженер техподдержки, как видите, это не низшее звено в цепи эволюции IT специалиста, а серьёзная работа. Ведь в первую очередь он всё-таки инженер. А как и в любой инженерной специальности, тут всё зависит исключительно от человека. Захочет станет признанным мастером своего дела и посвятит ему всю жизнь. И не важно, будет это работа у станка или со временем захочется научиться руководить другими инженерами. Хороший специалист никогда не пропадёт, а его работа должна (и будет) хорошо оплачена. А даже если со временем он решит кардинально сменить профиль деятельности, то всегда можно легко это сделать, с блеском применяя полученные ранее знания и умения.

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

^{Сокращённая версия этой статьи была залита ещё и на хх.}

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

1. ВВЕДЕНИЕ

Помимо преимуществ у автономных автомобилей есть и немало серьезнейших проблем.

• Водить даже обычный автомобиль бывает очень непросто, но ситуация дополнительно осложняется, если нужна автоматическая отказоустойчивая система, способная работать в любых условиях вождения с крайне низкими показателями допустимых ошибок. Автономные автомобили образуют и потребляют огромные объемы данных. При этом в новом отчете прогнозируется рост глобального рынка автомобилей с сетевыми возможностями на 270% к 2022 году. Предполагается, что к 2022 году будет продано свыше 125 миллионов пассажирских автомобилей с возможностями сетевого подключения [1].

• Суммарные расходы на разработку автономных систем вождения могут достигать миллиардов долларов, при этом стоимость оборудования одного автомобиля всем необходимым для полностью автономного вождения также будет весьма велика и может достигать 100 тысяч долларов [2].

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

• Также необходимо учитывать нормативно-правовые аспекты и вопросы ответственности. Например, если из-за автономного автомобиля возникнет авария, чья будет вина: водителя, производителя автомобиля или компании, разработавшей программное обеспечение для автономной езды?

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

Во все времена существования автомобилей именно технологии определяли самые современные возможности безопасности. С 70-х годов автопроизводители стали выпускать подушки безопасности, что позволило избежать множества человеческих жертв. Применение антиблокировочных тормозных систем, которыми автомобили оснащаются с 90-х годов, привело к снижению столкновений без человеческих жертв на 6-8% [3]. Тем не менее почти 1,3 миллиона человек ежегодно становятся жертвами дорожно-транспортных происшествий [4].

Передовые достижения в области высокопроизводительных вычислений и машинного обучения, использование новых технологий в датчиках (например, лидары технология получения и обработки информации дистанционного зондирования с помощью активных оптических систем (лазеров), использующих, в том числе, явления отражения света от поверхности Земли с проведением высокоточных измерений X, Y, Z координат) и мощные вычислительные системы периметра открывают новую перспективу снижение количества человеческих жертв в дорожно-транспортных происшествиях за счет реализации автономных автомобилей.

По мере роста экономики и урбанизации все более остро встает проблема перегруженности дорожных сетей. Средний городской житель проводит на дороге 40 минут в день. Таким образом, за год такой житель тратит 167 часов (свыше четырех полных рабочих недель) на сидение за рулем, и в течение этого времени он не может обращать внимание ни на что иное, кроме собственно вождения автомобиля.

Беспилотные автомобили будут играть важную роль в будущем умных городов и повлияют на построение и устройство городской инфраструктуры. В настоящее время только в США свыше 700 миллионов выделенных парковочных мест, занимаемая ими общая площадь сравнима с площадью всего штата Коннектикут. Автомобиль в среднем занимает парковочное место в течение всего 4% времени, тогда как при использовании беспилотных автомобилей коэффициент использования возрастает до 75% [5]. По этим причинам автономные автомобильные парки станут важным компонентом в умных городах будущего.

Распространение автономных автомобилей и транспортных решений совместного пользования может повлечь объединение бизнес-моделей агрегаторов такси и каршеринга.

Отчет, опубликованный компанией Allied Market Research, гласит, что объем глобального рынка автономных автомобилей составил 54,23 млрд долларов в 2019 году, а к 2026 году может вырасти до 556,67 млрд долларов, при этом совокупные темпы годового роста с 2019 по 2026 год составят 39,47% [6]. Для систем вождения высокой автономности (HAD) и полуавтономных функций в расширенных системах помощи водителям (ADAS) требуется платформа, способная получать и обрабатывать данные как в ядре, так и на границе сети. Высокопроизводительные решения HPE для хранения и архивации данных повышают надежность развертывания, обеспечивают защиту данных и их готовность к анализу. Множество решений HAD могут предоставляться по модели как услуга или по другим моделям потребления с оплатой по мере использования. Именно в этой области действуют решения пакета HPE GreenLake, упрощая обслуживание ИТ-инфраструктуры и сохраняя конфиденциальность и контроль над ней.

В этой статье рассматриваются проблемы HAD, включая составные части процесса разработки автомобилей с высоким уровнем автоматизации и автономности.

1.1. Общие характеристики задачи

1. Обнаружение. Решения HAD опираются на технологии автомобильных встроенных датчиков. Основные датчики: спутниковая система геопозиционирования (GPS), блок инерциальных датчиков (IMU), камеры, лидары, радары, ультразвуковые источники, а также различные датчики, установленные внутри автомобиля и в его силовом агрегате. Некоторые технологии уже широко применяются (например, GPS и камеры), тогда как другие (например, лидары) в настоящий момент достаточно дороги, однако по мере развития автономных автомобилей такие системы будут становиться дешевле и компактнее. Таким образом, на первом этапе необходимо преобразовать объем данных, поступающих от всего комплекса датчиков автомобиля, в подробное представление окружающей обстановки.

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

3. Распознавание объектов. На этапе обнаружения выделяются объекты вокруг автомобиля: другие автомобили, дорожная разметка, знаки дорожного движения, пешеходы, маршруты движения и т. п. Цель обнаруживать окружающие объекты и на основании этих данных строить картину окружающей обстановки, причем как при наличии карты высокого разрешения, так и на новой неизвестной местности. Разумеется, важно и обнаружение знаков дорожного движения, и обмен информацией между автомобилем и инфраструктурой, а также с другими автомобилями (V2X).

4. Восприятие. Для восприятия требуется передать модели новые собранные данные для распознавания объектов и их взаимоотношения с более крупными областями вокруг автомобиля. Компоненты этого этапа: локализация (где автомобиль?), контекстуализация (какая вокруг обстановка, возможно с использованием карт высокого разрешения?), распознавание объектов (интеграция данных с лидаров и с других датчиков) и отслеживание объектов (с помощью интеллектуальных моделей).

5. Принятие решения. Решение это подготовка к действию. Что автомобиль должен сделать? Повернуть? Затормозить? Продолжить ехать прямо? Бортовой компьютер автомобиля принимает решения на основе данных с датчиков, обработанных в контексте окружающей обстановки. Модели обучаются с помощью алгоритмов машинного обучения и огромного объема данных, полученных с комплексов автомобильных датчиков. это позволяет создать алгоритмы, способные предсказывать потенциальные события на основе поступающей в реальном времени ситуативной информации. После этого можно применять логические схемы для определения предпочитаемой последовательности действий. Основная цель состоит в составлении стратегии вождения: уклонении от препятствий, планировании поведения, управлении на основе данных GPS, планировании маршрутов, прогнозировании явно незафиксированных событий.

6. Действие. После принятия решения о дальнейших действиях автомобиль должен как можно быстрее приступить к их выполнению. Здесь требуется программный анализ, поскольку важно составить правильный план действий в зависимости от внешней обстановки. Если нужно, допустим, повернуть автомобиль влево, то летним днем на сухой дороге условия для этого будут совсем не такими, как зимой на скользкой дороге. Производители автомобилей уже делают шаги на пути к решению этой задачи: они уже сейчас предлагают функции помощи при перестроении и адаптивный круиз-контроль. Тем не менее по-прежнему очень непросто заставить систему управления правильно настроиться на внешнюю обстановку, в которой находится автомобиль.

От описания составных частей системы HAD перейдем к описанию ее важнейших компонентов. Данные с датчиков обычно собираются измерительными блоками в багажниках автомобилей. Первая задача при тестировании HAD заключается в выгрузке данных и в сохранении их в станции сбора данных (она также называется станцией отправки или станцией буферизации). Главное хранилище данных, как правило, представляет собой гибридное облачное решение с комплексом компонентов, по большей части расположенных в центре обработки данных (ЦОД) с возможностью использования облачных ресурсов при пиковой нагрузке.

В зависимости от сложности автомобиля и от степени использования программной эмуляции тестирование при разработке решений HAD обычно включает три этапа.

• Модель в контуре управления (MIL). Тестирование модели системы и операционной среды без проведения тестов на оборудовании HAD (часто выполняется на обычных рабочих станциях). Проверка MIL обычно проводится на ранних этапах цикла разработки.

• Программное обеспечение в контуре управления (SIL). Испытание и проверка автоматически созданного кода, используемого в контроллере системы. Тестирование SIL часто происходит в сэмулированной среде, также без проверки на системном оборудовании HAD.

• Оборудование в контуре управления (HIL). Тестирование и проверка системного оборудования HAD для выявления всех ошибок в архитектуре оборудования или вызванных используемым компилятором.

Данные, полученные от различных датчиков, используются для разных целей. Видеоданные можно хранить вместе с данными трансмиссии или информацией с лидара. Файлы данных хранятся на общем хранилище и используются для обучения моделей ИИ, а также для тестирования программного обеспечения и оборудования в контурах управления (SIL и HIL). Разработчики внешних датчиков используют эти данные для тестирования и усовершенствования автомобильных датчиков.

2. УРОВНИ АВТОНОМНОСТИ

В соответствии с подходом SAE (Society of Automotive Engineers), который поддерживается Национальным управлением по безопасности движения автотранспорта США (NHTSA), автономность автомобилей определяется по шестиуровневой иерархии (с Уровня 0 по Уровень 5).

• Уровень 0. Без автоматизации. Автомобилем всегда управляет только человек. При этом автомобиль может быть оснащен определенными системами предупреждения, но задача динамического вождения полностью выполняется человеком.

• Уровень 1. Помощь водителю. Автомобиль может выполнять определенные задачи, такие как замедление и ускорение, с помощью информации, полученной из окружающей среды. При этом человек должен всегда контролировать автомобиль и выполнять задачу динамического вождения.

• Уровень 2. Частичная автоматизация. Автомобиль может совершать маневры (перестраиваться из ряда в ряд), ускоряться и замедляться. При этом человек по-прежнему постоянно контролирует движение автомобиля и выполняет все остальные аспекты задачи динамического вождения.

• Уровень 3. Условная автоматизация. Автомобиль выполняет все аспекты задачи динамического вождения, но человек должен быть способен вмешаться в управление при необходимости.

• Уровень 4. Высокая автоматизация. Автомобиль выполняет все аспекты задачи динамического вождения и может принимать решения, даже если человек не отреагирует на запрос на вмешательство. Тем не менее это возможно лишь в определенных условиях вождения, например при совместных поездках в городской местности или в регионах, для которых составлены подробные карты.

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

Последние инвестиции и корпоративные приобретения свидетельствуют об интересе отрасли к разработке HAD и о стремлении как можно скорее добиться автономности Уровня 5. Корпорация Ford инвестировала 1 миллиард долларов в Argo AI [8]. Корпорация GM инвестировала средства в Lyft и приобрела Cruise Automation [9]. Корпорация Volvo создала совместное предприятие с Uber [10]. Корпорация Uber приобрела Otto [11]. Корпорация Intel инвестировала 15,3 миллиарда долларов для приобретения Mobileye [12]. Корпорации Hyundai и Toyota объявили о собственных инвестициях в исследования и разработку HAD. Это лишь небольшая, но достаточно репрезентативная выборка деятельности в этой весьма динамичной отрасли.

Некоторые производители рассматривают концепцию автономные автомобили как услуга и предполагают, что такая модель станет важным источником доходов. Автомобили Уровня 3 станут ключевым звеном для тестирования технологий и позволят решениям HAD выйти на массовый рынок.

Инициатива достижения Уровня 5 набирает все большие обороты. Тем временем крупнейшие автопроизводители осваивают направление автономных автомобилей самостоятельно либо заключают партнерские соглашения с другими компаниями, разрабатывающими такие программы. Все производители по-разному подходят к решению проблемы. Компания Waymo (принадлежит корпорации Alphabet/Google) объявила, что интересуется только Уровнем 5. Другие компании, такие как Uber и Ford, готовятся к Уровню 4 [13]. Корпорации Daimler и Bosch объявили [14] о планах разработки автономных автомобилей Уровней 4 и 5 с возможным стартом производства к началу следующего десятилетия. Другие компании выбрали последовательное развитие: по мере совершенствования технологий HAD они проходят каждый из уровней.

3. СБОР, ПРЕОБРАЗОВАНИЕ И АНАЛИЗ ДАННХ

Чтобы объединить все составные части инфраструктуры HAD, требуется организовать передачу больших объемов данных из автомобиля в центр обработки данных и в обратном направлении. Установленные в автомобиле (на границе сети) камеры, лидары и другие датчики генерируют огромные объемы данных, а в центре обработки данных производится обучение моделей ИИ и их настройка для принятия решений в реальном времени во время езды.

Поток данных от набора датчиков одного автомобиля составляет в среднем 33 Гбит/с, это примерно 120 ТБ данных за 8-часовую поездку. Технологии еще находятся на этапе разработки, поэтому в силу действующих правовых норм потребуется хранить весь объем данных с автономных автомобилей. Однодневный тест-драйв парка из 80 автомобилей это около 10 ПБ исходных данных. Следовательно, небольшой парк автомобилей будет генерировать от 100 до 500 ПБ данных в день.

3.1. Основные принципы

Кроме наличия гибкой, масштабируемой и высокопроизводительной файловой системы при создании среды исследований и разработки HAD необходимо создать возможности для параллельной разработки, моделирования и тестирования одновременно множеству разработчиков и команд разработки. Для поддержки этих потребностей со стороны разработчиков HPE может предоставить среды разработки, работающие по облачному принципу и расположенные как можно ближе к данным как в ядре, так и на границе сети.

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

Существуют инструменты для построения конвейеров непрерывной интеграции/непрерывной разработки (CI/CD), предоставляющие возможность гибкого и эффективного тестирования и разработки алгоритмов.

4. ПОИСК КОМПЛЕКСНОГО РЕШЕНИЯ HAD

Для систем HAD уровней 3 и 4 требуются современные информационные технологии. Корпорация HPE является одним из ведущих мировых поставщиков решений в области высокопроизводительных вычислений, предлагая мощнейшие решения своим заказчикам, имеющим самые сложные вычислительные задачи.

Конечная цель (уровень 5) в реализации автономных автомобилей повсеместно доступный каршеринг, причем все без исключения люди, находящиеся в автомобиле, являются его пассажирами (а не водителями), а часть пути автомобиль может проезжать вообще без людей в салоне. При этом автомобили будут обмениваться данными друг с другом, постоянно предупреждая о своих намерениях и ходе движения по маршруту. Для этого будут использоваться технологии беспроводной связи, такие как Wi-Fi и 5G.

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

Центральным хранилищем, куда стекаются все данные, является озеро данных: в нем хранятся все данные, собранные автомобилями, и все данные, сгенерированные в процессе работы системы. Различные этапы потока данных, предоставленного озером данных, см. на рисунках:

4.1. Регистрация данных

Бортовое оборудование тестовых автомобилей собирает данные, поступающие от датчиков, и сохраняет их, при этом скорость потока данных может превышать 30 Гбит/с. Например, если эксплуатационный парк из 80 автомобилей собирает 18 ТБ данных за 8-часовую смену при скорости 5 Гбит/с в каждом автомобиле, за всю смену будет сгенерировано 1,44 ПБ сырых данных. сли же такой же автомобильный парк генерирует данные на скорости 30 Гбит/с в каждом автомобиле, за смену будет создано 8,64 ПБ данных.

Для таких высоких скоростей данных рекомендуется конвергентная система для границы сети HPE Edgeline EL8000. Это универсальная модульная конвергентная платформа, объединяющей вычислительные ресурсы и ресурсы хранения данных, и допускающая подключение датчиков. Системы HPE EL8000 могут работать в более жестких условиях окружающей среды, чем стандартное ИТ оборудование, и поддерживают удаленное управление. HPE EL8000 это идеальный регистратор данных, представляющий собой интегрированное расширение центра обработки данных.

Система HPE EL8000 может принимать десятки гигабит данных в секунду от лидаров, радаров и видеопотоков, это практичная конвергентная автомобильная вычислительная платформа для тестирования и разработки. Каналы ввода-вывода шины PCIe в системах HPE EL8000 связаны напрямую с ЦП, обеспечивается непосредственный доступ к внутренней шине ЦП. Таким образом, данные напрямую движутся в память и из памяти, а также в кэш процессора и в другие устройства PCIe.

HPE EL8000 это не просто модуль хранения данных. Эта система поддерживает 64-разрядные ЦП x86 и специализированные ускорители вычислений, в том числе видеоускорители (GPU) и П ИС. В этом отношении HPE EL8000 представляет первый шаг конвейера преобразования данных. HPE EL8000 может устранить одно из узких мест потока данных за счет автоматической разметки содержимого тегами на лету. При этом снижается объем необходимых операций предварительной обработки.

4.2. Получение данных

Существует два способа выгрузки данных.

• Замена физических носителей. Система HPE EL8000 оборудована накопителями с поддержкой горячей замены; можно вставлять накопители в автомобильную систему и извлекать их. При этом в качестве носителей данных используются твердотельные накопители, чтобы свести к минимуму риск потери данных при манипуляциях и транспортировке. Носители информации передаются в местный центр сбора информации, информация с них считывается и по высокоскоростным каналам передачи данных передается в ЦОД.

• Выгрузка данных по высокоскоростным локальным сетям в станции сбора данных или центры обработки данных. В этом случае для выгрузки данных с автомобилей в станции сбора данных используется локальная сеть. Станции сбора данных расположены в центрах обработки данных, где автомобили подключают непосредственно к сети ЦОД. После подключения автомобили выгружают данные в указанные целевые системы по каналам с пропускной способностью 100 Гбит/с.

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

Станция сбора данных не только осуществляет буферизацию, но и служит первой точкой определения приоритета данных. В любом тест-драйве большая часть данных с высокой вероятностью не будет содержать важных событий и не будет представлять немедленной ценности для процесса разработки. Тем не менее некоторые события будут очень важны для разработчиков. Для таких случаев на станции сбора данных проводится приоритетная отправка, что дает возможность быстрее высвободить автомобиль и предоставить разработчикам самые важные данные в первую очередь. Разработчики могут применять различные алгоритмы определения приоритета, для которых могут потребоваться и более мощные вычислительные ресурсы, чем есть в HPE EL8000.

4.3. Озеро данных

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

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

Для параллельных файловых систем также доступны программные интерфейсы доступа по традиционным файловым протоколам систем POSIX, а также интерфейсы Hadoop, традиционные для Больших данных.

Некоторые клиенты пользуются другими распределенными крупномасштабными средами, включая Hadoop Distributed File System (HDFS), Ceph и даже решения, совместимые с S3. Например, HDFS работает на стандартном оборудовании и легко масштабируется. HDFS также назначить разные уровни хранения данных в зависимости от их температуры. Самые горячие данные, к которым требуется быстрый доступ, размещаются на самых быстрых накопителях, а холодные данные на менее скоростных дисках. Такой подход дает возможность создать озеро данных с невысокими затратами и оптимизировать систему с точки зрения важности данных и потребности в них.

4.4. Методики Программное обеспечение в контуре управления (SIL) и Оборудование в контуре управления (HIL)

В отчете, опубликованном в 2016 году [15], корпорация RAND подсчитала, что для снижения количества ДТП со смертельным исходом на 20 % автономные автомобили должны проехать около 11 миллиардов миль. сли использовать парк из 100 автомобилей, которые ездят круглосуточно 365 дней в году со средней скоростью 25 миль в час, для выполнения этой задачи потребуется 518 лет. Очевидно, требуется другое решение.

Для решения этой задачи компании, занимающиеся разработкой автономных автомобилей, применяют методики SIL и/или HIL, ускоряющие тестирование.

Корпорация HPE располагает опытом создания и поставки систем моделирования для автомобильных компаний во всем мире. В этих решениях HPE обычно использует шасси HPE Apollo 2000 Gen10 с серверами HPE XL170r для вычислений с использованием центрального процессора и с серверами HPE XL190r для вычислений с использованием видеокарт (GPU).

Индивидуальные рабочие процессы SIL создаются на основе системы контроля и управления (CMS). Система CMS поддерживает планирование событий по времени и обработку очередей действий, которые будут выполняться параллельно в зависимости от наличия свободных ресурсов.

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

Модель Оборудование в контуре управления (HIL) также можно интегрировать в основную сеть ЦОДа для организации высокоскоростного доступа к озеру данных. Поскольку требуется очень высокий уровень производительности, для конфигурации HAD предпочтительно использовать высокоскоростные среды передачи данных, такие как InfiniBand и Intel Omni-Path. Также стоит предусмотреть дополнительные каналы Ethernet 10 Гбит/с для реализации глобальной связности и индивидуальных проектов HIL.

4.5. Архивация и резервное копирование

Для создания системы HAD может потребоваться немало тестовых автомобилей, каждый из которых ежедневно генерирует терабайты данных. Легко заметить, что такой автомобильный парк может быстро создать сотни петабайт данных. При этом данные после их получения необходимо очищать, разделять и преобразовывать, создавая разные версии (в разных форматах) одной и той же информации.

Кроме того, в силу действующего законодательства и собственных политик, компании может также потребоваться архивация и резервное копирование данных. Для длительного хранения данных корпорация HPE предлагает решение Data Management Framework (DMF). Это иерархический диспетчер хранения данных с более чем 20-летней историей успешной эксплуатации. HPE DMF автоматически отслеживает свободное пространство в управляемой файловой системе. За счет этого гарантируется наличие необходимого свободного места, а системные администраторы избавляются от рутинной необходимости постоянно отслеживать загрузку ресурсов хранения данных и добавлять новые.

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

Ленточное решение HPE DMF построено на основе ленточной библиотеки HPE TFinity ExaScale на базе технологии Spectra. TFinity ExaScale это самая вместительная в мире отдельно стоящая система хранения данных [16]. Одна библиотека TFinity EE способна хранить до 53 450 ленточных картриджей на 44 шкафах.

При использовании технологии сжатия TS1150 емкость системы превышает 1 эксабайт. Благодаря решению Dual Robotics и 72 накопителям LTO-8 скорость записи достигает примерно 21 ГБ/с, а емкость 100,2 ПБ при использовании картриджей 8350 LTO-8 (четыре дорожки).

5. УСЛУГИ И РЕШЕНИЯ ПАРТНЕРОВ

Корпорация HPE занимает ведущую долю на рынке высокопроизводительных вычислений и обладает широчайшими возможностями для реализации решений HAD с самыми высокими требованиями к вычислительным ресурсам, системам хранения данных и сетевым ресурсам.

5.1. Создание

Организация HPE Pointnext Services создает полнофункциональную платформу для клиентов от центра обработки данных до конечных устройств (в данном случае это станции сбора данных и автомобильные регистраторы данных) и вплоть до готовых приложений для разработчиков. В зависимости от потребностей и целей клиента специалисты HPE Pointnext Services в области ИИ и обработки данных помогут:

• исследовать цели и приоритеты сценариев использования для бизнеса, данных и участников ИТ-экосистемы;

• определить функциональность ИИ и аналитики, необходимую для достижения поставленных целей;

• выявить зависимости и источники данных для выработки стратегии интеллектуальной обработки данных.

5.2. Выполнение

Запуск в эксплуатацию налагает требования по необходимому уровню операционной поддержки для всех компонентов, чтобы обеспечить оптимальную доступность для поддержки бизнеса. Предоставляя услуги операционной поддержки HPE Pointnext Services, корпорация HPE может помочь в реализации операционных задач системы HAD.

Услуги адаптивного управления HPE являются составным компонентом решений HPE GreenLake: ИТ-услуги предоставляются по модели с оплатой за использование. Эта платформа позволяет решать эксплуатационные задачи для инфраструктуры компании, включающей серверы, системы хранения данных, сети, инфраструктурные программные решения, гипервизоры, системы резервного копирования и восстановления данных, а также средства безопасности, а также межплатформенное и прикладное ПО, разработанное компанией HPE и определенными сторонними поставщиками.

5.3. Потребление

Если вам требуется гибкость и полный контроль в локальной среде или публичном облаке, воспользуйтесь предложением HPE GreenLake это набор ИТ-решений с оплатой по фактическому потреблению. Предлагаем каталог полных проверенных решений, позволяющих добиться нужных результатов в области ИТ с использованием оборудования, программного обеспечения и знаний на ваших площадках по модели с оплатой за использование.

5.4. Партнеры

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

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

6. ЗАКЛЮЧЕНИЕ

В дорожно-транспортных происшествиях во всем мире ежегодно гибнет около 1,35 миллиона человек. Аварии на дорогах обходятся большинству стран в 3% их внутреннего валового продукта. От 20 до 50 миллионов человек получают несмертельные травмы, часто приводящие к нетрудоспособности [18].

Автомобили высокой автономности стремительно растущий рынок, цель повышение безопасности и здоровья общества. По оценкам специалистов, если распространение автономных автомобилей достигнет 10, 50 и 90%, это может привести к снижению числа человеческих жертв соответственно на 1100, 9600 и 21 700 человек в США за год [19].

Разумеется, HAD непростая задача. Для ее решения требуются самые передовые и совершенные технологии, доступные на рынке в настоящее время, включая нейросети машинного обучения и глубинного обучения, современные ускорители вычислений, высокопроизводительные сети и среды передачи данных.

Предложения HPE позволяют удовлетворить потребности автомобильной промышленности в современных решениях ИИ и высокопроизводительных вычислений для облачных развертываний HAD. При этом клиенты могут приобрести и эксплуатировать решения самостоятельно, а также заключить договор с HPE (используя HPE Pointnext Services, HPE GreenLake и другие предложения услуг) и поручить нашей корпорации обработку некоторых или всех вычислительных задач для HAD. Корпорация HPE предлагает полный ассортимент вычислительных систем, сетевых решений, систем хранения данных и технической поддержки и услуг по всему миру, гарантируя, что разработчики уже сегодня могут приступить к созданию оптимальных решений HAD для надежных и безопасных транспортных сетей будущего.

Том Фентон специально для StorageReview рассмотрел аспект хранения dHCI и выяснил, можно ли им управлять так же эффективно, как и вычислениями.

В недавней статье мы рассмотрели одну из наиболее интересных технологий, которые в настоящее время используются в центрах обработки данных: дезагрегированную гиперконвергентную инфраструктуру (dHCI). В частности, мы рассмотрели внедрение dHCI компанией HPE, так как она является лидером в этой технологии. Напомним, что dHCI похож на гиперконвергентную инфраструктуру (HCI) в том смысле, что позволяет управлять хранилищем, вычислениями и сетью с единой платформы управления (в случае HPE vCenter Server); однако, в отличие от HCI, dHCI не требует развертывания хранилища синхронно с вычислительными ресурсами. Поставщики dHCI сознательно отсоединили хранилище от вычислительных ресурсов, чтобы предоставить центрам обработки данных свободу комплексного расширения своих платформ, тем самым предотвращая проблему нехватки ресурсов, характерную для имплементаций HCI. Этот дисбаланс с развертыванием HCI объясняется тем, что очень небольшое количество приложений увеличивает вычисления с той же скоростью, что и хранилище. В этой статье мы рассмотрим аспект хранения dHCI и выясним, можно ли им управлять так же эффективно, как и вычислениями.

Установка HPE Nimble dHCIEnvironment

Чтобы лучше понять систему хранения в среде dHCI и то, как это решение компании HPE автоматизировало и упростило процесс настройки и управления dHCI, мы развернули его в среде с существующими серверами vCenter. Мы заранее предполагали, что это будет напоминать стандартный опыт пользователей при первоначальном развертывании dHCI. Наш исходный кластер dHCI будет состоять из двух вычислительных узлов, подключенных к массиву HPE Nimble Storage и управляемых с помощью vSphere через плагин HPE dHCI.

Для вычислительных узлов мы использовали серверы HPE DL360 Gen10. Эти серверы имеют два процессора Intel Xeon 6130, 128 ГБ оперативной памяти и резервированные диски для ОС. На этих системах были предустановлены VMware ESXi 6.7u1 и Nimble toolkit.

Для хранения мы использовали HPE Nimble из линейки AF: в частности, массив AF20Q с 12 накопителями SSD емкостью 960 GB, обеспечивающими 5.8 TiB пространства для хранения. Для подключения AF20Q имеет четыре 10Gb порта на контроллер, два из которых мы использовали как цели iSCSI, а два других для управления.

Для подключения всех систем мы использовали HPE FF 5700 32XGT. Этот свитч имеет 32 порта 10Gb Base-T, восемь 10Gb SFP+ и два 40 Gb QSFP+.

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

Следуя инструкцииHPE Nimble Storage dHCI and VMware vSphere Deployment Guide, сначала мы установили HPE Nimble Storage, затем создали и добавили вычислительные узлы, и, наконец, создали кластер. В разделах, расположенных ниже, мы расскажем о нашем опыте работы с этим процессом.

Настройка HPE Nimble Storage

Мы подключили наш лэптоп к той же сети, что и массив HPE Nimble Storage. Затем мы открыли браузер и ввели серийный номер массива в формате https://<серийный номер>.local. Это вызвало веб-мастер настройки HPE Nimble.

Мы выбрали опцию Set up this array (but do not join a group) и нажали Далее. В мастере мы указали имя для массива и параметры сети, и создали пароль для массива. Инициализация массива заняла несколько минут, после чего он вызвал конфигуратор стека. Мы вошли в систему как admin. В верхней части мастера была диаграмма, демонстрирующая ход процесса установки.

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

Подключение к существующему серверу vCenter

Выбрав Connect, мы подключились к веб-странице сервера хранения и вошли в систему под именем admin. Мы установили флажок Use an existing vCenter Server, а затем указали информацию для сервера vCenter. В мастере также есть возможность создать новый сервер vCenter.

Нас спросили, хотим ли мы использовать существующий кластер или создать новый: мы выбрали создание нового. Затем нам было предложено ввести имя нового дата-центра и кластера.

Мы выбрали два сервера ESXi, которые мастер обнаружил автоматически. Мы указали IP-информацию для iSCSI и пароли для серверов ESXi и iLO. Затем нам предложили добавить хранилище данных, что мы и сделали. Мы создали хранилище данных VMFS.

Нам представили сводку введенных параметров конфигурации, после чего был создан кластер dHCI. Этот процесс включал в себя настройку серверов ESXi, настройку кластера, регистрацию плагина vCenter Server и настройку хранилища. Затем нам предложили запустить интерфейсы vCenter или HPE Nimble. Мы выбрали Launch vCenter UI, однако, если бы мы выбрали Launch HPE Nimble Storage UI, мы могли бы получить более расширенные настройки, такие как шифрование, интеграция с AD и интеграция с Cloud Volumes. HPE сообщил, что эти функции вскоре будут доступны в плагине vCenter dHCI.

Нас интересовало, насколько автоматизирован процесс внедрения HPE Nimble Storage dHCI в новой среде, поэтому мы наблюдали, как это делает HPE.

Развертывание в новой системе

Среда, которую использовала HPE, была аналогична той, в которой мы выполняли развертывание в существующей системе. Развертывание в существующей инфраструктуре позволяет ИТ-администраторам использовать имеющиеся серверы HPE ProLiant и подходящие коммутаторы. Развертывание с нуля предполагает использование новых вычислительных узлов, хранилища и коммутаторов. Первоначальная установка Nimble Storage была точно такой же, как и в нашей среде.

Выбрав Connect, они подключились к веб-странице сервера хранения и вошли в систему под именем admin. Они установили флажок Create a new vCenter Server, а затем указали информацию для сервера.

Их попросили указать название нового дата-центра и кластера: они выбрали ESXi и указали IP-информацию для iSCSI и пароль для серверов ESXi. Последним шагом был выбор типа хранилища данных (VMFS или VVol) для vCenter Server.

Им представили сводку выбранных параметров конфигурации, после чего был создан кластер dHCI. Этот процесс включал в себя настройку и выполнение того же, что и в нашем развертывании, с добавлением установки vCenter Server. Затем им предложили запустить интерфейсы vCenter или HPE Nimble.

Честно говоря, мы были несколько удивлены глубиной автоматизации и интеграции, которую HPE внедрила в это решение, независимо от того, существующее ли это или новое развертывание. HPE потребовалось меньше времени на настройку всего кластера dHCI, включая настройку vCenter Server, чем на установку, настройку и интеграцию vCenter Server с массивом хранения SAN.

Плагин vCenter

Мы вернулись в нашу среду dHCI, вошли на наш сервер vCenter и выбрали HPE Nimble Storage. Доступ к нему можно получить с помощью ярлыков или раскрывающегося меню.

HPE Nimble Storage всегда поддерживал тесные отношения с vCenter через его плагин, и нам было интересно увидеть, как они использовали этот опыт в своем решении dHCI.

Первое, что мы заметили это то, что все уже было полностью установлено и настроено, и нам не нужно было ничего делать для его использования. Внешний вид плагина такой же, как и у vCenter Server: он разделен на разные секции и имеет шесть разных вкладок вверху, относящихся к управлению кластером dHCI.

Открыв плагин, мы убедились, что наши серверы и хранилище показаны на вкладке Inventory. Открыв вкладку Storage, мы увидели различные разделы для пулов хранения, массивов и партнеров репликации.

Открыв вкладку Servers, мы увидели различные разделы для хостов. В разделе Server Health было указано, что наши источники питания не резервированы.

Повседневные операции

Большим плюсом dHCI является то, что повседневные операции, такие как мониторинг, обслуживание и добавление хранилища и вычислительных блоков, а также проверка правильности конфигурации кластера, могут выполняться через централизованную консоль управления.

Знакомство с повседневными операциями мы начали с исследования хранилища кластера. Мы выбрали вкладки Datastores, а затем vVols. Мы нажали значок + и получили возможность добавить дополнительные хранилища данных VMFS или vVols.

В то время как классические типы томов известны очень хорошо, vVols известен в меньшей степени. Это весьма странно, так как vVols существует уже более половины десятилетия, выведя дата-центры на новый уровень абстракции. HPE была одним из первых поставщиков, внедривших vVols, и одним из самых убежденных ее сторонников и эта приверженность vVols очевидна в их плагине dHCI.

Мы создали новое хранилище vVols, выбрав VVOL в раскрывающемся меню Datastores и нажав значок+, чтобы вызвать мастер настройки. В этом мастере мы указали имя и атрибуты хранилища данных vVol, пространство, которое мы хотим выделить для него, и требуемые ограничения IOPS или MiB/s.

Создав хранилище данных vVol, мы создали для него политику хранения из клиента vSphere, выбрав Policies and Profilesв раскрывающемся меню.

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

Создав политику, мы создали новую виртуальную машину (VM) и указали для нее политику хранения.

Вернувшись к плагину dHCI, мы выбрали VVol VMs. На этой вкладке можно было увидеть виртуальные машины, использующие vVols. Инновационная черта архитектуры HPE Nimble заключается в том, что у вас есть 72 часа на восстановление VM после ее удаления. VM также можно копировать на этой вкладке.

Если у вас есть виртуальные машины, использующие тома VMFS, но вы хотитеперенести их на тома vVols, вы можете выполнить миграцию средствами vMotion.

HPE Nimble dHCI Configuration Checker

Другая инновационная функция плагина dHCI Configuration Checker. Запуск средства проверки конфигурации позволит убедиться, что ваш dHCI настроен правильно. Выполняемые им проверки варьируются от довольно тривиальных до очень глубоких. Наша система проверила 66 правил и нашла 2 ошибки. Эти проверки варьировались от верификации путей до массива до проверки привилегий администратора iLO.

Хотя одним из основных преимуществ dHCI, как отмечалось выше, является его способность раздельно масштабировать вычисления и хранилище, это преимущество может быть сведено на нет, если это будет сложно или неудобно выполнить. Плагин dHCI упрощает добавление дополнительных вычислительных ресурсов (серверов ESXi) к кластеру dHCI.

Нажатие значка + вызывает мастера, который сканирует вашу сеть на наличие хостов ESXi, которые можно добавить к кластеру. После того, как вы выберете хост, который хотите добавить, и введете всю информацию (IP, ESXi и пароль iLO), он будет автоматически добавлен в кластер. После добавления он будет настроен с необходимыми vSwitches, портами VMKernel, инициаторами iSCSI и настройками брандмауэра, и на нем будут включены HA и DRS.

HPE InfoSight

HPE Nimble Storage надежный инструмент хранения данных, однако одной из причин, по которой HPE купила его еще в 2017 году, был InfoSight. InfoSight изначально разрабатывался для управления ресурсами хранения данных и поддержки клиентов, осуществляемых с использованием инновационных проприетарных алгоритмов прогнозирования и искусственного интеллекта (AI). Однако HPE увидела ценность этой технологии в более широком спектре своих продуктовых линеек, поэтому HPE InfoSight теперь поддерживает серверы, сети и системы хранения HPE. Используя Infosight, HPE постоянно обрабатывает невероятный объем имеющихся метаданных, а затем использует эти данные для обнаружения корреляций при возникновении проблем. Затем он оповещает клиентов об этих проблемах, чтобы они могли вовремя решить их, чтобы предотвратить простои и другие сбои в работе.

На техническом уровне HPE InfoSight состоит из HPE InfoSight Engine, который собирает и анализирует данные с помощью системного моделирования и алгоритмов прогнозирования. Механизм работает в облаке, а доступ к нему осуществляется через портал HPE InfoSight, содержащий информацию о ваших системах. Наконец, модуль Proactive Wellness отправляет превентивные предупреждения для систем, а также контролирует их общее состояние.

Настроив HPE InfoSight в нашем кластере dHCI и предоставив ему возможность поработать несколько дней для сбора данных, мы получили доступ к порталу HPE InfoSight через веб-браузер. Мы вошли на веб-страницу HPE InfoSight и выбрали наш dHCI-кластер HPE Nimble Storage. На главном экране отображались наш массив Nimble Storage, хосты ESXi и количество развернутых виртуальных машин, а также показатели использования ресурсов кластера.

Нажав на кластер dHCI, мы перешли на страницу с подробной информацией по нему.

Синий текст на портале это гиперссылки, которые можно использовать для более глубокого изучения объектов. Нажав на сервер, мы увидели огромное количество низкоуровневой информации о нашей среде VMware, а также о наших серверах хранения и вычислений.

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

HPE InfoSight также имеет информационные панели для отображения предварительно настроенной информации, начиная от рекомендаций и возможностей и заканчивая общим обзором системы. Кросс-стековая аналитика для VMware позволяет администраторам не только получать представление о своих виртуализированных средах, но и получать инструкции по устранению неполадок. Весной 2020 года HPE InfoSight представил консолидированную систему рекомендаций для VMware и HPE Nimble Storage, которая была интегрирована в веб-портал InfoSight. Эта система рекомендаций, объединяющая информацию, специфичную для VMware, стала возможной благодаря машинному обучению (ML) и экспертным знаниям, которые используют одноранговое обучение на основе обширной телеметрической информации, предоставляемой установленной системой HPE.Ниже приведен пример кросс-стековой аналитики и рекомендаций по виртуальным машинам.

Ниже приведен пример административной панели, показывающей рекомендации по экономии.

Обновление HPE Nimble dHCI

Обновления одна из самых болезненных операций, с которыми сталкивается администратор. Необходимость проверки совместимости, и того, что все необходимые компоненты обновляются в правильной последовательности, может нервировать даже самого стойкого администратора. К счастью, плагин dHCI делает это за вас и обновит прошивку массива, Nimble Storage Connection Service (NCS) и узлы ESXi в кластере.

Чтобы выполнить обновление, вы выбираете кластер dHCI, который хотите обновить, открываете вкладку Update, а затем выбираете обновление, которое хотите инициировать. Файлы, необходимые для обновления, включая ISO-образ ESXi, загружаются через плагин.

После завершения предварительной проверки будет обновлен массив HPE Nimble, а затем серверы.

Обновления выполняются последовательно, чтобы исключить простои кластера.

Заключение

dHCI может изменить правила игры в сфере обработки данных, поскольку сочетает в себе простоту управления HCI с гибкостью раздельного развертывания хранилища и вычислений. Однако, dHCI сможет изменить правила игры только в том случае, если будет реализовываться правильно (а не просто объединяя массив хранения с серверами). Необходимы аппаратное и программное решения, которыми можно полностью управлять, от развертывания до повседневных операций, из центральной панели управления и похоже, что HPE достигла именно этого с помощью HPE Nimble Storage dHCI.

Легкость и простота развертывания начального кластера dHCI, добавления хранилища и вычислений, а также обновления системы были поистине впечатляющими. Кроме того, HPE использовала свои обширные знания системы vVols и полностью интегрировала их в свое решение. Мы также оцениваем HPE InfoSight как бесценный инструмент, гарантирующий, что система будет иметь меньше проблем с поддержкой. HPE Infosight делает это возможным благодаря расширенной прогностической поддержке и профилактическим рекомендациям ИИ, делающим возможным упреждающее, а не реактивное управление системой. Говоря кратко, HPE реализовала dHCI так, как надо.

Перефразируя известного киногероя, Бэкапы это хорошо. Бэкапы это надежно. И чем больше опций для создания резервных копий есть у провайдера, тем лучше: клиенты получают возможность выбрать ровно то, что требуется бизнесу, ни больше, ни меньше.

В облаках ИТ-ГРАД и #CloudMTS мы развернули сразу три сервиса резервного копирования: на базе Veeam, Acronis Infoprotect и Commvault. С их помощью можно собрать решение под любую задачу. Под катом поговорим о причинах появления такого разнообразия и разберем, какие задачи пользователь может решать с помощью того или иного сервиса.

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

Veeam

Veeam стал первым внедренным нами сервисом резервного копирования данных в рамках IaaS. Сейчас порядка 70% наших клиентов пользуются именно им. С его помощью можно бэкапить как инфраструктуру в облаке, так и локальные площадки.

Резервное копирование IaaS

Самый джентльменский сервис в нашем пуле базовый бэкап на Veeam. Это простое решение всё из коробки, не требующее дополнительных настроек. При подключении услуги всем ВМ клиента автоматически назначается единая политика резервного копирования:

• ежедневная инкрементная резервная копия;

• еженедельная полная копия;

• срок хранения 14 дней.

Доступа к порталу управления у пользователей базового бэкапа нет, поэтому процедура восстановления осуществляется по заявке в саппорт. Как правило, запрос на восстановления выполняется в течение рабочего дня.

Кому подходит: небольшим проектам, для которых гибко настраиваемое резервное копирование не принципиально. С одной стороны, данные виртуальных машин сохраняются и могут быть восстановлены в случае ЧП. С другой отсутствует возможность гибко вносить изменения. Однако в любой момент можно перейти с базового бэкапа на использование более продвинутых решений.

Если базового бэкапа мало, можно перейти на Veeam Self-Service и управлять всеми задачами резервного копирования и восстановлением через веб-портал самообслуживания, интегрированный с vCloud Director

Через портал Self-Service можно настраивать:

• наименования заданий, количество точек восстановления и глубину хранения;

• график запуска заданий, количество попыток выполнения и время между попытками, окно для резервного копирования;

• ВМ/vApp, которые нужно бэкапить в рамках конкретного задания;

• папки и файлы, который нужно включить или исключить из заданий;

• уведомленияи многое другое.

Отметим, что для заказчиков, арендующих инфраструктуру в защищенном сегменте, развернута отдельная инсталляция сервиса. Решение в Облаке ФЗ-152 функционально идентично тому, что размещено в публичном, за исключением опции базового бэкапа. По очевидным причинам в защищенном сегменте облака провайдер не имеет права работать с данными за клиента даже с точки зрения резервного копирования.

Резервное копирование с площадки клиента

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

1. C помощью Veeam Cloud Connect Backup, если у клиента уже есть сервер Veeam Backup & Replication не ниже версии Enterprise в рамках собственной инфраструктуры.

   VCC позволяет бекапить:

   • физические серверы с ОС Windows и Linux;

   • виртуальные машины на базе VMware и Hyper-V;

   • рабочие станции на Windows и Linux.

2. С помощью Veeam Agent, если сервер Veeam B&R отсутствует. Агенты также позволяют бэкапить физические сервера, ВМ и клиентские машины, но только с Windows.

Дополнительные фичи

Если на стороне клиента есть Veeam B&R, можно реализовать DR-сценарии. Veeam Cloud Connect Replication позволяет быстро переключаться как на уровне отдельных виртуальных машинам, так на уровне всей площадки. После активации реплик в облаке запустятся копии ВМ, соответствующие по состоянию последним репликам.

Для кого подходит: Veeam Enterprise Manager позволяет закрыть сразу множество типовых клиентских задач: полноценная интеграция сервиса резервного копирования с облаком, копирование с площадки клиента в облачный репозиторий, DR и т.п. Это весьма практичное и универсальное решение, которое подходит подавляющему большинству заказчиков.

Тем не менее, Veeam не позволяет осуществлять кроссплатформенную миграцию и в рамках агентского бэкапа ОС поддерживает только Microsoft Windows.

Acronis Infoprotect

При всей своей гибкости и универсальности решение Veeam подходит не всем заказчикам. Если в крупном и среднем сегменте его использование оказывалось выгодным, то небольшим компаниям требовалась альтернатива с хорошим соотношением цена/качество. Мы проанализировали запросы таких клиентов и добавили в свой пул решение Acronis Infoprotect.

По возможностям копирования БД и приложений продукт Acronis близок к описанному выше Veeam. Однако Acronis Infoprotect:

• дешевле;

• без агента бэкапит ВМ множества платформ (VMware, Hyper-V, Virtuozzo, KVM, RHEV, Citrix XenServer, Nutanix AHV, Oracle VM при наличии доступа к гипервизору);

• в рамках агентского бэкапа работает не только с Windows, но и с Linux и macOS;

• умеет защищать от вредоносного ПО (в т.ч. от майнеров и вымогателей) выявляет нетипичную активность, блокирует попытки изменения файлов и автоматически восстанавливает их, если что-то повредить удалось;

• поддерживает кроссплатформенную миграцию.

Для кого подходит: Acronis Infoprotect закрывает практически все задачи малого и среднего бизнеса. Заказчики могут без проблем бэкапить данные с собственных площадок в облако, даже если в компании нет выделенного специалиста под эти задачи с веб-интерфейсом Acronis Infoprotect легко подружиться, имея минимум технический знаний.

Кроссплатформенная миграция

Очень часто клиенты после некоторого времени использования нашего облака в качестве площадки для хранения данных переносили к нам свою инфраструктуру. На такой случай в арсенале Acronis имеется одна полезная функция Universal Restore. С ее помощью можно переводить физические серверы в облачные или мигрировать между разными гипервизорами. Для миграции заказчику достаточно сделать резервную копию и восстановиться в облаке.

Commvault

Это серьезное и многопрофильное решение Enterprise-уровня. Оно умеет работать как с инфраструктурой в облаке провайдера, так и с собственными площадками заказчика.

Commvault позволяет восстанавливать любые элементы инфраструктуры (от отдельных файлов до платформ и ИС), реализовать DR-сценарии, мигрировать между платформами.

Отдельно стоит рассказать о том, с чем умеет работать Commvault:

• базы данных: Oracle, Microsoft SQL, MySQL, IBM DB2, MongoDB, PostgreSQL, Cassandra, DB2, Documentum, Hadoop, Informix, SAP for HANA, SAP MaxDB, SAP for Oracle, SQL Server, Sybase.

• ОС (в рамках агентского бэкапа): Windows, Linux, Mac, Unix, FreeBSD, Solaris, NetWare;

• платформы: VMware, Hyper-V, Azure Stack, OpenStack-KVM, Citrix XenServer, Huawei FusionCompute, Nutanix AHV, Oracle, Red Hat Virtualization;

• приложения: Microsoft: Exchange, Active Directory, SharePoint, Office 365, Skype for Business; Lotus: Notes Database/Document, Domino; SAP; EMC Documentum, Cloud Apps.

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

Для кого подходит: Enterprise-продукт, в арсенале которого найдется всё для решения бизнес-задач крупных компаний.

Сравним функционал и возможности всех рассмотренных сегодня продуктов.

Итог

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

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

Резервное копирование Acronis Infoprotect бюджетное решение, которое сможет удовлетворить задачам малого и среднего бизнеса. К тому же, продукт включает несколько удобных дополнительных функций.

Если у компании уже есть сервер Veeam Backup and Replication резервные копии для большей надежности могут дополнительно храниться в облаке провайдера. Либо они полностью перенесены в облачный репозиторий для минимизации трат на закупку оборудования для локального хранения бэкапов.

Полнофункциональный продукт на основе Veeam Enterprise Manager подойдет среднему и крупному бизнесу с серьезными бэкап-запросами, уже перенесшего инфраструктуру в облако провайдера.

Решение на базе Commvault это дорогой серьезный продукт, ориентированный на большие компании со специфическими требованиями к организации резервного копирования.

Сегодня я решил поразмышлять на тему зачем нам это надо (на примере Notion)? Пост чистая философия.

Вообще, я к Notion не имею никаких претензий. Никто же не предъявляет претензии молотку Просто это первый сервис, который мне попался, который обладает огромным функционалом.

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

И вот он - Я. По классике жанра сразу создал 2 пространства личное и рабочее. Сами понимаете - жизнь именно так и делится. Вот тут мои книги, вот тут фильмы, тут заметки, тут лайфхаки, тут идеи, тут полезное что-то, рецепты, тренировки, уроки, курсы, друзья, семья, машина, животные, хобби И самое вкусное планы!

Начнем с простого. Книги, фильмы, музыка. Создал каталоги: что смотрел, что читал, что слушал, что планирую читать, смотреть, слушать. Даже какие-то рейтинги придумал, что понравилось, а что не очень, оценки от 0 до 5, нет до 10, так объективнее, теги по жанрам. Даже где-то писал комментарии.

Потом. Списки уроков, курсов, полезных материалов, гайдов, мануалов. Всё разложил по полочкам, теги опять же.

Друзей оцифровал. Фото там, дни рождения, дни рождения детей, ссылки на соцсети, контакты Теги

Хобби, животные, машина, всё оцифровал, навешал тегов, добавил ссылок на ресурсы

Работа! Тоже все оцифровал по аналогии. Прям всё! В общем, всё по феншую.

Планы наше спасение и наша погибель. Notion помогает раздуть их до вселенских масштабов. Пришла в голову идея в планы ее, задачи к ней, подзадачи к ним, сроки каждой задаче/подзадаче, ответственных лиц и всё такое. Это все на волне эйфории от гениальности идеи. Чем она гениальнее мне казалась, тем больше места она занимала в Notion.

Что получил в итоге.

Сначала был вопрос а на хера мне всё вот это вот? Кому интересно, да и в принципе кто это увидит, что я читал, смотрел, слушал и как у меня всё это отсортировано? Все эти рейтинги для самого себя? Если мне понравился фильм, то на кинопоиске я поставил оценку и забыл про него. С книгами еще проще: прочитал удалил. Всё. Нет книги. Музыка. Вся она в яндексмузыке в подборке понравилось (и то, что-то удаляю, что-то добавляю). Всё. На хрена она в Notion?

Друзья. Все в телефонной книге. Кого забыл поздравить с днюхой - не обижайтесь.

Далее. Всё остальное, что было указано выше. Если возникает вопрос, то самое простое загуглить. Информация имеет свойство становиться неактуальной. Поэтому гугл решает. Да и быстрее загуглить, чем лазить и искать нужную инфу в Notion (и да, про поиск я в курсе).

Планы. Спустя неделю я смотрел на очередную идею как на какую-то херню. Именно такие мысли и посещали (некоторые даже мата достойны не были). И уже не было никакого желания что-то делать. Но! так как я ее породил, то убивать ее рука не поднималась. Поэтому она так и болталась, а я тешил себя несбыточной надеждой, что когда-нибудь реализую эту херню.

И вот к каким выводам я пришел.

Всё это мы делаем, что улучшить нашу продуктивность. Тут трудно поспорить. Что бы и идеи, и планы, и задачи, и ресурсы, и всё необходимое, всё под рукой, и я такой бодрый и веселый несу миру радость от выполнения поставленных самим собой перед самим собой каких-то там планов. И все у меня разложено по полочкам и все подписано на разных стикерах. И всё благодаря Notion. Получается так что, мы получаем больше положительных эмоций оцифровывая свою жизнь, чем от самой жизни. И я считаю, что это неправильно.

Вместо того, чтобы жить, мы пишем, как бы мы хотели жить. И все что мы делаем теперь зависит от того, что записано в Notion. А если не записали, значит этого нет. И Notion превратился из инструмента в цель, в смысл. Вместо того, чтобы что-то сделать и порадоваться этому и забыть, мы делаем чтобы порадовать тому, что что-то сможем записать вечером в Notion. После выполнения не наступает радость или облегчение. Они наступают после того как поставил галочку в списке выполненных задач или после записи в планировщике. А если не записали, то день прошел зря. И этот вывод не на пустом месте появился. Посмотрите сколько роликов на ЮТ этому посвящено, сколько шаблонов создано. Все это говорит о том, что люди относятся к простой программе как к спасению (именно так) своей жизни.

У кого-то жизнь стала лучше, после того как он загнал себя в цифровой формат? Напишите в комментах (с).

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

Жизнь надо жить, работу работать, с друзьями и близкими - общаться, книги читать, фильмы смотреть, музыку слушать, целей достигать и т.д. и т.п. Этого вполне достаточно, что бы чувствовать себя полноценным.

В итоге я всё меньше и меньше пользовался сервисом. Что, кстати, сам за собой замечал и радовался. А сейчас вообще забросил и ни капли об этом не жалею.

P.s. Есть такое понятие: создать википедию из своей жизни. Вот именно этим многие и пытаются заниматься благодаря этому сервису. Я никого не осуждаю. Ваша жизнь и вам ее жить.

А я не хочу, чтобы моя превратилась в 0 и 1.

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

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

В одном из прошлых постов (ссылка) мы говорили о результатах исследования Acronis Cyber Readiness Report. Отчет показал, что более трети всех компаний в мире столкнулись с проблемой подключения и управления новыми устройствами. И проблема обеспечения надежной защиты данных на этих часто вообще никак не сконфигурированных для рабочих процессов компьютеров, является не единственной. Оказалось, что обеспечить постоянную доступность удаленного рабочего места тоже непросто особенно с учетом явного смещения фокуса внимания киберпреступности на удаленных работников.

По данным исследования Acronis Cyber Threats 2020 (ссылка), За прошлый год 31% компаний были атакованы каждый день, причем версии вредоносного ПО постоянно обновлялись среднее время жизни одного экземпляра не превышало 4 дня. Подобное положение дел создает реальный риск взлома хотя бы одной системы из корпоративного периметра (который давно уже не периметр, а решето). При этом аналитики из Aberdeen сообщают, что стоимость простоя рабочих мест на протяжении часа даже для СМБ может составлять до $8,600 в час. В случае с крупным бизнесом все еще хуже при неудачном стечении обстоятельств, простой может обойтись в сотни тысяч долларов в час по мнению аналитиков Gartner.

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

Интеграция компонентов играет ключевую роль

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

Самый простой пример интеграция между системой резервного копирования и средствами киберзащиты на базе ИИ. Если в компании регулярно создаются резервные копии, значит искусственному интеллекту можно предложить огромное количество примеров рабочего места или сервера, который находится в нормальном состоянии. Применив к этому набору данных методику машинного обучения, мы можем повысить эффективность обнаружения вредоносной активности, а также лучше распознавать многократно проверенные процессы то есть снизить уровень ложных срабатываний. Такой подход помогает сэкономить время специалистов и сократить время простоя систем.

С другой стороны, восстановление рабочего места из резервной копии в ручном режиме это достаточно затратная по времени задача. Более того, иногда сотрудники, находящиеся в удаленном режиме работы, не могут сделать это самостоятельно, и тогда приходится говорить о дополнительном времени простоя, подключении ИТ-специалистов и так далее.

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

Патчи и самовосстановление

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

Поэтому, если мы говорим о реальной устойчивости систем к атакам, к потребностям восстановления хочется добавить еще один аспект установку патчей. Это позволяет дополнительно снизить потенциальное время простоя, исключая возможность повторной атаки через те же самые бреши. Сейчас в большинстве случаев этим занимается ИТ-департамент. И существует целый ряд причин, по которым патчинг происходит нерегулярно. Однако при интеграции в общий контур киберзащиты системы патч-менеджмента мы можем автоматизировать этот процесс.

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

Как это будет работать на практике?

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

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

Нередко наши клиенты, уже использующие облака для работы с персональными данными, задаются вопросом: а подходят ли облачные сервисы для бэкапов ПДн? Сегодня мы на собственном опыте покажем, какие требования к резервному копированию ПДн и данных ГИС предъявляют регуляторы, как их выполняет сервис-провайдер в облаке и как мы решаем насущные задачи клиентов по обеспечению доступности персональных данных при использовании распределенной инфраструктуры.

Требования со стороны регуляторов

Практически все наши клиенты используют сервисы резервного копирования. При этом, работая с персональными данными, они понимают, что регуляторы предъявляют достаточно высокие требования к безопасности такой чувствительной информации. Предлагаем на нашем провайдерском опыте разобраться, как эти меры выполняются в облаке.

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

Если как следует ознакомиться с основным регулирующим законом, 152-ФЗ О персональных данных, а именно со ст. 19, можно увидеть следующее:

Статья 19. Меры по обеспечению безопасности персональных данных при их обработке

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

2. Обеспечение безопасности персональных данных достигается, в частности:

7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;

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

Вывод 1, очевидный. Бэкапы не являются задачей на усмотрение оператора ПДн, а, согласно требованиям 152-ФЗ, лежат в его зоне ответственности: резервное копирование ПДн его прямая обязанность.

Строя свою ИС, работающую с ПДн и ГИС, важно учитывать требования приказов ФСТЭК 17 и 21, которые относят средства резервного копирования к средствам защиты информации.

Приказ ФСТЭК 17:

20. Организационные и технические меры защиты информации, реализуемые в информационной системе в рамках ее системы защиты информации, в зависимости от угроз безопасности информации, используемых информационных технологий и структурно-функциональных характеристик информационной системы должны обеспечивать: доступность информации

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

Приказ ФСТЭК 21:

ЗСВ.8 Резервное копирование данных, резервирование технических средств, программного обеспечения виртуальной инфраструктуры, а также каналов связи внутри виртуальной инфраструктуры

ОДТ.4 Периодическое резервное копирование персональных данных на резервные машинные носители персональных данных

ОДТ.5 Обеспечение возможности восстановления персональных данных с резервных машинных носителей персональных данных (резервных копий) в течение установленного временного интервала

Вывод 2. Клиент, работая с ПДн в облаке, обязан решить вопрос доступности информации и, как следствие, регулярно выполнять резервное копирование.

Помимо приказов выше, необходимо обратить внимание на следующие нормативные документы:

• Приказ ФСБ 416, ФСТЭК 489 от 31.08.2010

• Постановление Правительства от 18.05.2009 424

Эти документы указывают на необходимость использования средств оперативного восстановления информации и фиксируют максимальное время восстановления доступа к потерянным или измененным вследствие несанкционированного доступа данным не более 8 часов.

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

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

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

Пользователи облака, аттестованного по 152-ФЗ, получают в свое распоряжение готовую инфраструктуру, готовую к работе с ПДн. Другие сервисы, используемые в защищенном облаке, также должны соответствовать требованиям регуляции. BaaS-решения не исключение. Поэтому провайдер, предоставляя пользователям защищенной инфраструктуры бэкап-инструменты, помимо технических возможностей выполнения резервного копирования, должен обеспечить и соответствие требованиям регуляции.

Как решаются вопросы бэкапа со стороны провайдера

Наше облако аттестовано по требованиям УЗ-1 и К1, соответственно, в нем уже решены два типа задач:

• резервное копирование непосредственно облачной инфраструктуры и обеспечение высокой доступности данных;

• предоставление бэкап-сервисов пользователям этого облака.

В части обеспечения доступности информации (ОДТ) мы как провайдер решаем следующие задачи:

• Периодическое резервное копирование конфигурации компонентов инфраструктуры защищенного сегмента на резервные носители информации (ОДТ.4).

• Обеспечение возможности восстановления конфигурации компонентов инфраструктуры защищенного сегмента облака с резервных носителей (т.е. из резервных копий) в течение установленного временного интервала (ОДТ.5).

В части защиты среды виртуализации (ЗСВ):

Резервное копирование данных, резервирование технических средств, программного обеспечения виртуальной инфраструктуры, а также каналов связи внутри виртуальной инфраструктуры защищенного сегмента облака (ЗСВ.8).

Технически эти требования по резервному копированию облачной инфраструктуры реализуются на базе продуктов Veeam. Они хорошо зарекомендовали себя в системах виртуализации. Но это не единственная причина, почему для сегмента 152-ФЗ мы выбрали именно это решение:

• Veeam Backup & Replication имеет сертифицированную версию с классификацией по 4-му уровню отсутствие декларированных возможностей;

• благодаря наличию сертификата с ним легко проходить аттестацию.

Использование этого решения позволяет нам не только защищать свою инфраструктуру, но и предоставлять возможности резервного копирования пользователям нашего защищенного облака. С помощью Veeam пользователи облака могут бэкапить компоненты своей ИС, выполняя все требования регуляторов, которые мы обсудили выше.

Клиенты нашего облака в рамках одной инфраструктуры получают не только соответствующее 152-ФЗ IaaS-решение, но и готовый инструмент бэкапа, ответственность за который лежит на наших плечах. Пользователю остается лишь корректно настроить задачи резервного копирования и следить за их выполнением.

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

Однако клиенты не всегда ограничиваются исключительно сервисами одного провайдера. Многие используют собственные мощности или набор облаков различных поставщиков. Именно поэтому более сложна и интересна ситуация, когда у клиента существует потребность бэкапить персональные данные со своей локальной площадки в облако. Мы как провайдер помогаем таким клиентам решать эту задачу с использованием наших BaaS-сервисов.

Бэкап персональных данных с собственной локальной площадки в облако

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

Рассмотрим каждый из этих вопросов подробнее на практике.

1. Как выполнить безопасный обмен данными между площадкой клиента и облаком?

   Есть два способа: зашифровывать бэкап перед отправкой либо воспользоваться защищенным каналом для передачи бэкапа. Поскольку представленные современные средства резервного копирования не имеют функционала сертифицированных средств шифрования, соответственно, не имеют каких-либо сертификатов СКЗИ, первый вариант отпадает. Поэтому систему нужно построить накладными средствами, решив вопрос защиты каналов с помощью установки криптошлюзов.

   Клиент, работая с облаком, привык пользоваться гибкими решениями и инструментами. В облаке, как известно, не приветствуется использование программно-аппаратных решений, поэтому стоит обратить внимание на виртуальные криптошлюзы.

   У такого подхода есть очевидные плюсы. Виртуальный шлюз легко и быстро устанавливается, не требует колокации и лишних затрат, у него отсутствуют характерные для аппаратных решений проблемы. Кроме того, виртуальные шлюзы (в отличие от аппаратных) хорошо масштабируются с точки зрения производительности при увеличении задействованных vCPU растет и производительность решения. Работа с ВМ, которая будет представлять криптошлюз, не требует удаленных рук и присутствия инженеров на площадке.

2. Как защитить площадки, участвующие в обмене данными, при подключении к публичным сетям?

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

   В облаке мы используем виртуальные криптошлюзы. Да, такие решения могут не иметь сертификатов необходимого уровня по межсетевому экранированию, однако это и не нужно. Аттестованное облако уже защищено общим сертифицированным межсетевым экраном, поэтому надобность в применении отдельных сертифицированных решений отпадает.

3. Реализация отказоустойчивой архитектуры решения

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

Своим клиентам мы предлагаем решение на базе продуктов С-Терра. Этот инструмент решает все задачи организации высоконадежной и защищенной связности двух площадок для передачи бэкапов ПДн. В линейке продуктов С-Терра имеются различные варианты программно-аппаратных и виртуальных криптошлюзов. Благодаря широкой линейке можно подобрать оптимальное решение как по производительности, так и по и отказоустойчивости. Производительность шлюзов С-Терра в зависимости от модификации варьируется от 100 Мбит/c до 10 Гбит/с, поэтому и клиент, и мы как провайдер всегда сможем подобрать наиболее оптимальное для своих задач решение.

Варианты подключения локальной площадки клиента к BaaS-сервису

Обмен данными между площадками может быть организован двумя способами.

1. Veeam Cloud Connect Backup

   Схема используется в том случае, когда у клиента есть сервер Veeam Backup & Replication. Он выполняет резервное копирование объектов со своей площадки, а облако используется как репозиторий. Связь организуется между самим Veeam Backup & Replication и репозиторием через описанный выше защищенный канал связи.

   

2. С использованием агентов

   В случае, когда у клиента отсутствует сервер Veeam Backup & Replication на своей площадке, вместо него для резервного копирования используются агенты на серверах и ВМ. Управление осуществляется через Veeam Service Provider Console.

   

Эти сценарии в дальнейшем могут обеспечить и другие возможности.

• Восстановление в облако провайдера

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

• Миграция инфраструктуры

В случае, если клиент хочет перенести данные с одной площадки на другую, VCC позволяет решить и такую задачу.