Спасительные облака

Не знаю как остальных, но лично меня настораживают модные слова и технологии типа виртуализации, облаков и BigData. Настораживают, потому что, не вникая в их суть и применимость, люди слепо начинают их использовать, где нужно и не нужно, потому что «другие же это делают!», в итоге создавая решения, в которых проблем больше чем решений (например, считая, что гигабайт — это big data, разворачивают Hadoop, вместо того, чтобы добавить памяти и использовать Excel). Поэтому я особо скрупулезно вгрызаюсь в модные технологии, пытаясь понять их специфику и область их применимости, дабы не поддаться самому «синдрому молотка». В этой статье хочу поделиться некоторыми своими мыслями насчет облачных хранилищ, тем более что таковое завелось у нас в Acronis несколько лет назад.

Куда уходит детство?

Как-то мой брат, как любой нормальный человек, собрался в отпуск с семьей. Накануне отъезда он явился в родительский дом с внешним жестким диском и сказал: «Пусть полежит тут». На вопрос «что это и зачем нужно?» (ну а вдруг там коды наведения ракет или неопубликованные материалы Wikileaks), он ответил, что это одна из нескольких резервных копий фоток его детей, и что на случай пожара или ограбления его пустующей квартиры именно эти фотки он не хотел бы потерять. Ведь деньги и технику можно восстановить методом заработка. Утерянные фотки детей не восстановить никак из-за мерзопакостного второго начала термодинамики – время в нашем мире уходит безвозвратно. В этом основная функция бэкапа – остановить утекающее время. В этом и заключается ценность бэкапа – замороженное время. Но тут возникает интересный момент: будучи ценным, бэкап сам нуждается в бэкапе! Так получается сценарий репликации резервных копий. Но, как говорится, бессмысленно класть все яйца в одну корзину. Так что резервные копии должны быть рассредоточены в пространстве. Можно унести родителям, а можно и в облако. Мой брат явил мне первый пример оффсайт бэкапа, который мне запомнился навсегда.

Плоть от плоти, бэкап от бэкапа

Итак, если мы воистину дорожим нашими данными, то нам нужны резервные копии их резервных копий. Однако с увеличением количества копий перед нами встает проблема, с которой сталкивается злостный кодер-копипастер – проблема согласования. Для примера, у меня как-то полетел внешний диск Western Digital с резервной копией фоток (после чего я испытываю лютое недоверие к WD). С тех пор я копирую фотки на два диска, но это создает дополнительную нагрузку для синхронизации этих копий. Втыкать и вытыкать USB диски – это не то, чем я хотел бы заниматься остаток своей жизни. Было бы круто, если бы кто-то копировал резервные копии за меня.
В продукте Acronis Backup & Recovery этим занимается сам продукт, умеющий реплицировать созданные цепочки бэкапов в дополнительное хранилище. Например, так решаются сценарии D2D2T (disk to disk to tape) либо D2D2C (disk to disk to cloud).
В продукте Acronis True Image избыточность бэкапов решается бэкапом в облако. Ведь в облаке Acronis репликацией занимаются аж двое – Рид и Соломон, копирующие данные по нескольким узлам хранения, так что при сбое одного узла, данные не теряются. О деталях реализации облака как-нибудь расскажу подробнее в другом посте.

Копирование в облако

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

1. География
2. Законодательство
3. Объем копируемых данных
4. Частота изменения данных
5. Ширина канала
6. Время работы компьютера без перезагрузок
7. Важность согласованности данных

География и законодательство

Учитывая глобальность доступности облака, при перемещении в него данных возникает вопрос – а не против ли государство, чтобы вы это делали? Например, если дата-центр находится в Сирии, пользователи из США будут ощущать безопасность своих данных не так глубоко, как хотелось бы. В Старом Свете стандарты по передаче персональных данных уходят корнями еще в Древний Рим, так что передача на кассетах под конвоем зачастую единственный способ легально перевезти данные из банка в банк, не говоря уже о том, чтобы хранить их неведомо где.

Технические факторы

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

Объем копируемых данных

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

Частота изменения данных

Если бы данные не менялись, то им и резервные копии-то не были особо нужны (это если посчитать уничтожение данных одной из форм изменения). В зависимости от частоты изменения так же возникает вопрос – важно ли пользователю отслеживание каждого изменения или некоторые изменения могут быть проигнорированы. Например, при редактировании DOC файла пользователю может быть интересно отследить все сохраненные версии документа (некое подобие постоянного высокоуровневого undo стека), между тем как отслеживание модификации каждого блока файла базы данных мало кому интересно. Частота изменения данных напрямую влияет на поддержание их согласованности, что особенно болезненно ощущается на загруженных продакшен системах с созданным мгновенным снимком (snapshot), приводящим к дублированию I/O операций на запись.

Ширина канала

Если канал широкий (типа шины процессора или быстрой локальной сети), то тонким местом является чтение с самого диска. Оптимизация заключается в минимизации I/O операций с диском, что достигается однопроходным копированием диска, или снятием образа (imaging). Однако, если узкое место – это канал связи, то I/O операции с диском перестают играть ключевую роль и на передний план выходят другие факторы.

Время работы без перезагрузок

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

Согласованность данных

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

Сценарии работы с облаком

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

Синхронизация

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

1. На всех узлах, подлежащих синхронизации устанавливается агент
2. Агенту задается некая область для отслеживания (папка, набор папок, целый том)
3. Агент отслеживает изменения и тут же заливает их в облако, если оно доступно либо откладывает до появления связи
4. Агент подписывается на события в облаке и проигрывает их локально
5. Версионность файлов за счет резервного копирования происходит в самом облаке.

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

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

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

При таком канале заливка сотни гигабайт занимает часы, а то и дни. С большим объемом можно бороться инкрементальными копиями, но от первичного большого объема никуда не деться. Если корпоративные клиенты еще могут кое-как вытерпеть такое время, то домашний пользователь выключит свой компьютер в первый же день. Терпеливые корпоративные клиенты тоже не будут особо довольны несколько дней держать активным мгновенный снимок (о боже, привнеси в русский язык слово snapshot!) системы, удваивающий I/O операции. У этой проблемы есть два решения:

1. Первичная закачка (initial seeding)
2. Докачка

Первичная закачка

Суть этого решения заключается в том, чтобы этот первичный объем данных передать в центр обработки данных не по медленному и ненадежному каналу типа HTTP, а по быстрому (для больших объемов) и надежному каналу типа реальная физическая почта (надежному, если это не Почта России). То есть пользователь копирует свою резервную копию на реальный диск и посылает его по почте типа DHL в центр обработки данных. Там его распаковывают, и после этого пользователь по обычному WAN-у инкрементно копирует небольшие изменения в своих данных в облако. То, что физический канал может быть довольно быстрым, подтверждает известная шутка, иллюстрирующая безумную пропускную способность канала, нагрузив КамАЗ жесткими дисками и разогнав его до 60 км/ч. Кстати, когда мой брат принес диск в родительский дом, он, по сути, сделал этот самый initial seeding. Так как отсылка и отслеживание дисков довольно энергоемкая задача, а домашних пользователей много (у Acronis их более пяти миллионов), это решение в просюмерском сегменте не устраивало компанию Acronis чисто организационно. В корпоративном сегменте устраивало, где успешно и применяется.

Докачка

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

Гибридное снятие образа

В True Image 2013 впервые в Acronis (и в мире!) реализовано (а в True Image 2014 значительно улучшено) гибридное снятие образов. Алгоритм выглядит следующим образом:

1. Создается мгновенный снимок файловой системы
2. Технологией снятия образов копируется пустой том с базовой загрузочной информацией (объем этот не превышает 200 Кб)
3. Файлы из снимка инкрементально копируются в облако

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

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

Россия и облако

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

Целенаправленное копирование данных российских пользователей за пределы Российской Федерации встречается с юридическими актами и ограничениями, так что прежде чем давать такую возможность, наши только-только зарождающиеся кибер-законы должны быть всесторонне исследованы. Так или иначе, ходят слухи, что ничего противоправного в нашем законодательстве не обнаружено, и одном из ближайших обновлений европейское облако станет доступно также и российским домашним пользователям. Ну а там, если пользователей будет много, возможно, их данные будут мигрированы на родину!
Что же касается тех домашних пользователей True Image 2014, никаких технических ограничений нет, и кто все-таки хочет попробовать облако, находясь в России, можно выставлять в своем онлайн аккаунте какую-нибудь другую европейскую страну (например, Польшу) и пользоваться облаком. Корпоративным пользователям Acronis Backup & Recovery 11.5 никаких особых приседаний не нужно – там все работает из коробки.

Заключение

• Облако – это первичное хранилище для оффсайт бэкапа
• Облако само обеспечивает избыточность
• Облако надежное, но не совсем доступное хранилище, что нормально для хранилища резервных копий
• Доставка данных в облако – сложная задача, в зависимости от потребностей и сценария решаемая одним из нижеприведенных способов:
  • Синхронизация
  • Первичная закачка
  • Гибридное снятие образа