Veeam Backup v.8. Полезные мелочи

Вышел Veeam Backup & Replication v.8 What's New in v8

По традиции, в Veeam Bakup & Replication, в каждой новой версии много интересных вещей. В этот раз файл what's new вышел аж 12 страницах мелким шрифтом. И, понятное дело, что все смотрят в первую очередь на топовые функции (типа интеграции со снимками NetApp или Backup I/O Control).
И при этом мало обращают внимание на некоторые из тех изменений, что скрываются под "и 200+ других улучшений".

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

Snapshot hunter

Снапшоты VMware – не только зло, но и головная боль администратора.
Есть такая печальная ситуация, когда в суслика снапшоты у ВМ не видно, а они физически есть на диске. Вот KB от VMware: http://kb.vmware.com/kb/1002310.
Теперь задание VBR v.8 просканирует датасторы VMware на наличие недобитых снапшотов, и попытается их удалить (консолидировать) по процедуре, описанной в KB. Если удалить не получилось (файлы заблокированы), задание завершится с предупреждением. Но фоновый процесс продолжит попытки удалить (по умолчанию 3 попытки через 4 часов каждая). Если снова неудача, будет отправлено письмо с предупреждением о ситуации.

Дизастэ Рикавери своими руками

С марта собирался написать про это.

«Дешевое» решение

После одного из европейских VMUG (VMware User Groups – когда собираются те, кто не равнодушен к технологиям виртуализации от VMware и делятся опытом) появились скрипты, как самому сделать DR для сервисов в виртуальной инфраструктуре VMware.

Первоисточник с презентацией тут. 

Состав:

1. Площадки с развернутой VMware vSphere – 2 штуки
2. СХД с репликацией между ними – 2 штуки
3. ВМ – в ассортименте
4. скрипты Power Shell (вот прямая ссылка) – 1 набор
5. голова и руки – по вкусу

Готовка:

BCP & DRP

Есть два понятия, которые довольно часто люди путают.
BCP — Business Continuity Planning — план работ по предотвращению возникновения и исправлению последствий в случае возникновения ситуаций, негативно влияющих на работу компании.
DRP — Disaster Recovery Plan — план восстановления инфраструктуры компании после возникновения аварии.

При этом, как правило, ИТ служба вовлечена в оба плана. А так как зачастую ИТ дистанцировано от непосредственно бизнеса, то понятия и путают.

Итак, что это за планы, и с чем их курят?


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

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

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

RTO и RPO

UPDATE! Теперь это серия статей по теме RTO/RPO

Список статей:

Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html

Решил статью про одно написать, а углубился в другое... :)

Публикую в качестве ликбеза.

При разработки технических решений по защите данных и сервисов бизнес-задач предприятия обычно оперируют двумя основными понятиями:

• время восстановления (recovery time objective (RTO)) - допустимое время простоя сервиса в случае сбоя.
• точка возврата (recovery point objective (RPO)) - допустимый объем возможных потерь данных в случае сбоя.

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

Если вы, допустим, социальная сеть, то простой пару часов - плохо: люди уже начнут смотреть на конкурентов - но еще не критично - тут свою роль играет раскрутка ресурса, и насколько подсажены на этот ресурс пользователи. (RTO)

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

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

Отмечу, что значения RTO и RPO - это экстремумы - максимальные значения. Т.е. сколько нам максимум времени нам бизнес позволяет на простой, или сколько максимум данных (по времени) мы можем потерять.
Пример. RPO = 1 сутки. Значит копированием производим, по-старинке, раз в день (ночью). Если у нас резервное копирование запускается в 1:00, а у нас произошел сбой в 0:59, то мы и потеряли как раз сутки. Если сбой произошел сразу по успешному завершению резервного копирования - то вы ничего не потеряли.

Важно! Для RPO, если бизнес поставил значение, резервное копирование должно производится не реже этого значения!

То же касается и RTO. Если указано значение, а вы восстановили доступность сервиса/данных раньше - хорошо, соблюли бизнес-требование. Если потратили больше - не хорошо.

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


Продолжение...

VMware vCenter SRM

Недавно контора проводила сейшн для наших клиентов: «Технология виртуализации. Катастрофоустойчивость виртуальной инфраструктуры»

Там и фото есть меня - мааленькое, правда.

И вот я подумал, собрался, и таки решил опубликовать по мотивам презентации, которую я вел:

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

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

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

Для защиты от катастроф – выход из строя части серверной комнаты, либо целого ЦОДа – одним из такого рода решений и является построение резервного ЦОДа.