Как правильно спроектировать архитектуру хранилища резервного копирования виртуальной инфраструктуры? Прежде всего, нужно ответить на ключевой вопрос: “Что является главным приоритетом: минимизация использования дискового пространства, производительность или стоимость?” Ответ на этот вопрос определяет всю дальнейшую стратегию инвестирования в бэкап-инфраструктуру.
На рисунке изображен один из оптимальных вариантов архитектуры инфраструктуры резервного копирования. СХД «первой линии» (на рисунке — это Backup Storage, изображенный слева от линии передачи данных), расположенное в непосредственной близости от оригинальных данных продуктивной сети, должно быть максимально быстрым (например, оно может быть построено на SSD дисках), но оставаясь при этом разумным по цене. Чтобы достичь такой цели, это хранилище должно иметь размер, достаточный для хранения только тех данных, которые с наибольшей вероятностью могут быть истребованы для восстановления при системном сбое или по запросу пользователей продуктивной сети. Например, если по вашей статистике до 80% запросов на восстановление приходятся на данные, созданные, модифицированные или удаленные за последние 30 дней, то только эти данные и нужно хранить на СХД «первой линии». При выборе этого СХД нужно учитывать следующие рекомендуемые свойства:
Итак, подводя итог, с точки зрения резервного копирования преимущество данной схемы заключается в следующем:
Если репозиторий хранит много резервных копий одной и той же инфраструктуры, разумно применить дедупликацию данных, что позволит уменьшить требуемое дисковое пространство СХД.
Специализированные СХД с дедупликацией, такие как ExaGrid, Data Domain, HP StoreOnce и другие, являются хорошим выбором для этой задачи. Также хорошим вариантом может быть применение программной дедупликации, встроенной в Windows Server 2012. Veeam Backup работает как с аппаратной, так и с программной дедупликацией, встроенной в ваше хранилище, и, кроме того, содержит собственную встроенную дедупликацию — и здесь вы имеете полную свободу, какую именно дедупликацию применять, а это в свою очередь уже зависит от структуры ваших данных и функциональности вашего СХД. Например, СХД серии ExaGrid EX автоматически сохраняют часто используемые данные в распакованном (ре-дедуплицированном или «регидрированном») виде, что позволяет им очень быстро возвращать такие данные на операциях чтения, так что только скорость сети будет ограничивающим фактором при выполнении операций восстановления из резервных копий. Это особенно важно в задачах восстановления виртуальных машин «на лету» прямо из резервной копии в песочницу, как это, например, происходит при работе технологии Instant VM Recovery. Дополнительно о вопросах дедупликации в резервном копировании можно прочитать в отчете ESG lab «Virtual Machine Backup Without Compromise» (англ.яз.).
Планирование дискового пространства под репозиторий резервных копий является непростой задачей, чем-то сходной с планированием расхода топлива автомобиля — фактически пройденный километраж будет варьироваться от случая к случаю и будет зависеть от многих факторов. И, в итоге, это возвращает нас к исходному вопросу: «что важнее — скорость, стоимость или размер дискового пространства». Последующие вопросы, приоритеты и ограничения зависят от конкретных пользовательских сценариев, ИТ инфраструктуры и структуры самих данных.
На рисунке изображен один из оптимальных вариантов архитектуры инфраструктуры резервного копирования. СХД «первой линии» (на рисунке — это Backup Storage, изображенный слева от линии передачи данных), расположенное в непосредственной близости от оригинальных данных продуктивной сети, должно быть максимально быстрым (например, оно может быть построено на SSD дисках), но оставаясь при этом разумным по цене. Чтобы достичь такой цели, это хранилище должно иметь размер, достаточный для хранения только тех данных, которые с наибольшей вероятностью могут быть истребованы для восстановления при системном сбое или по запросу пользователей продуктивной сети. Например, если по вашей статистике до 80% запросов на восстановление приходятся на данные, созданные, модифицированные или удаленные за последние 30 дней, то только эти данные и нужно хранить на СХД «первой линии». При выборе этого СХД нужно учитывать следующие рекомендуемые свойства:
- Высокая производительность: Применение высокопроизводительного СХД на «первой линии» позволяет, с одной стороны, максимально быстро дублировать/реплицировать происходящие изменения в оригинальных данных, и, с другой стороны, быстро восстанавливать требуемые данные, что дает хорошие показатели RPO и RTO соответственно.
- Малый объем: За высокую производительность нужно платить, поэтому, емкость СХД первой линии не должна быть большой. При планирование размера этого хранилища нужно исходить из объема данных, которые с наибольшей вероятностью могут быть истребованы к восстановлению, для чего имеет смысл проанализировать статистику обращений в HelpDesk на предмет вопроса «за какой период времени происходит 80% обращений за восстановлением данных» именно в вашей организации. Ответ на этот вопрос может оказаться в диапазоне от 7 до 30 дней, что означает, что более поздние резервные копии должны перемещаться на СХД долговременного хранения (гораздо большего размера, но менее производительное и более низкое по цене из расчета за единицу хранимой информации).
- СХД является источником для последующих заданий резервного копирования: С СХД первой линии данные нужно копировать дальше по цепочке: в репозиторий долговременного хранения или даже за пределы офиса, а, возможно, по нескольким точкам назначения одновременно. Поэтому такое СХД должно обеспечивать высокую скорость не только на операциях записи, но и на операциях чтения. Подробнее о «backup copy заданиях» с использованием WAN акселератора можно посмотреть в записи вебинара: "Backup copy jobs with built-in WAN acceleration" (англ. яз.)
Итак, подводя итог, с точки зрения резервного копирования преимущество данной схемы заключается в следующем:
- Новые и измененные данные продуктивной системы дублируются максимально быстро (хорошее RPO)
- Резервные копии наиболее часто требуемых к восстановлению данных находятся на быстром СХД и максимально близко (с точки зрения сети) от оригинальных данных (хорошее RTO)
- Копии, размещенные вне офиса или в репозитории долговременного хранения данных, создаются асинхронно относительно копий, создаваемых в процессе первичного дублирования данных. Таким образом с процесса первичного дублирования информации снимаются дополнительные риски, связанные с передачей больших объемов данных через WAN или медленные участки сети (риски, связанные, прежде всего, с тем, что процесс может затянуться и начнет отрицательно влиять на RPO).
Если репозиторий хранит много резервных копий одной и той же инфраструктуры, разумно применить дедупликацию данных, что позволит уменьшить требуемое дисковое пространство СХД.
Специализированные СХД с дедупликацией, такие как ExaGrid, Data Domain, HP StoreOnce и другие, являются хорошим выбором для этой задачи. Также хорошим вариантом может быть применение программной дедупликации, встроенной в Windows Server 2012. Veeam Backup работает как с аппаратной, так и с программной дедупликацией, встроенной в ваше хранилище, и, кроме того, содержит собственную встроенную дедупликацию — и здесь вы имеете полную свободу, какую именно дедупликацию применять, а это в свою очередь уже зависит от структуры ваших данных и функциональности вашего СХД. Например, СХД серии ExaGrid EX автоматически сохраняют часто используемые данные в распакованном (ре-дедуплицированном или «регидрированном») виде, что позволяет им очень быстро возвращать такие данные на операциях чтения, так что только скорость сети будет ограничивающим фактором при выполнении операций восстановления из резервных копий. Это особенно важно в задачах восстановления виртуальных машин «на лету» прямо из резервной копии в песочницу, как это, например, происходит при работе технологии Instant VM Recovery. Дополнительно о вопросах дедупликации в резервном копировании можно прочитать в отчете ESG lab «Virtual Machine Backup Without Compromise» (англ.яз.).
Планирование дискового пространства под репозиторий резервных копий является непростой задачей, чем-то сходной с планированием расхода топлива автомобиля — фактически пройденный километраж будет варьироваться от случая к случаю и будет зависеть от многих факторов. И, в итоге, это возвращает нас к исходному вопросу: «что важнее — скорость, стоимость или размер дискового пространства». Последующие вопросы, приоритеты и ограничения зависят от конкретных пользовательских сценариев, ИТ инфраструктуры и структуры самих данных.
