Ожидаемый в этом году Veeam Availability Suite v9 содержит ряд новых возможностей для крупных компаний. В подобных организациях часто возникают трудности с масштабируемостью и управлением удаленными офисами и филиалами (ROBO).
Одной из сильных сторон наших решений является собственная технология взаимодействия с гостевыми ОС виртуальных машин, которая гарантирует корректное резервное копирование и восстановление. Veeam не использует постоянно действующие агенты внутри виртуальных машин. При старте бэкап-задания на каждой виртуальной машине с включенной опцией «Application Aware Image Processing» запускается специальный временный модуль. Это происходит автоматически, и по окончании резервного копирования модуль удаляется. Процесс, который запускается на ВМ, координирует работу VSS и обеспечивает выполнение необходимых шагов для каждого поддерживаемого приложения, включая усечение журнала транзакций и индексацию гостевой файловой системы.
В предыдущих версиях взаимодействие с гостевыми ОС осуществлял сервер резервного копирования. Именно центральная консоль отвечала за установку временного модуля на каждую ВМ (по сети или с помощью VIX API). Такой механизм всегда отлично работал, но по мере увеличения размеров и сложности среды появилось два ограничения.
Во-первых, масштабируемость. Количество ВМ в типичной среде заказчика сильно возросло, поэтому ресурсов сервера резервного копирования стало иногда не хватать. Получалось, что сервер может параллельно взаимодействовать только с ограниченным количеством ВМ. В противном случае наблюдались задержки в выполнении бэкапа.
Второе ограничение тесно связано с первым. В крупных компаниях обычно имеется несколько удаленных офисов с локальной средой. При этом сервер резервного копирования, как правило, размещают на центральной площадке, и все взаимодействие с гостевыми ОС в удаленных офисах происходит по каналу WAN. Скорость передачи данных при этом зачастую оставляет желать лучшего.
Можно разместить в удаленном офисе репозиторий и прокси-сервер резервного копирования — тогда данные ВМ при бэкапе и восстановлении не будут покидать пределы площадки. Однако для взаимодействия сервера резервного копирования с гостевыми ОС все равно придется использовать WAN. Это тоже приведет к проблемам с масштабируемостью.
Для решения этих проблем в v9 представлен Guest Interaction Proxy — прокси-сервер для взаимодействия с гостевыми ОС. Роль Guest Interaction Proxy может выполнять любой сервер под управлением Microsoft Windows (в том числе, существующий прокси-сервер или репозиторий). Идеальным вариантом будет прокси-сервер, так как он обычно находится ближе всего к виртуальным машинам.
Если разместить Guest Interaction Proxy на удаленной площадке, то по WAN будут передаваться только команды управления от сервера резервного копирования. Именно Guest Interaction Proxy будет устанавливать временный модуль на ВМ и управлять взаимодействием с гостевыми ОС. Таким образом, объем WAN-трафика и нагрузка на сервер бэкапа снизятся. Поскольку один сервер резервного копирования может контролировать сразу несколько Guest Interaction Proxy, масштабируемость значительно возрастет. Например, представьте себе компанию с 500 удаленными площадками. На каждой площадке можно развернуть прокси-сервер и назначить ему роль Guest Interaction Proxy. Контролировать все эти машины будет сервер резервного копирования. Для улучшения взаимодействия с большим количеством ВМ можно развернуть несколько Guest Interaction Proxy в пределах одного крупного дата-центра.
У технологии есть еще одно малозаметное преимущество — доступ к гостевой ОС при невозможности использования VIX API. Например, если учетная запись для взаимодействия с ВМ не может быть использована из соображений безопасности. В таком случае вы можете использовать компьютер под управлением Windows с двумя сетевыми интерфейсами — в производственной сети и в сети резервного копирования. В качестве Guest Interaction Proxy компьютер будет «пересылать» трафик от сервера резервного копирования в производственную сеть.
Однако новая технология может применяться не только для резервного копирования. Надежно хранимую в репозитории информацию когда-то может потребоваться восстановить. При восстановлении данных в удаленном офисе придется задействовать центральный сервер резервного копирования. Именно к нему подключаются резервные копии при восстановлении на уровне файлов.
Если репозиторий расположен локально, данные все равно будут дважды передаваться по сети WAN — сначала на сервер резервного копирования, а потом обратно на удаленную площадку, для восстановления. Можно попробовать обойти WAN — например, использовать мастер для восстановления файлов (FLR wizard) и соответствующую программу. Но у этого метода тоже есть свои недостатки.
С версией 9 вам не придется искать обходные пути, ведь в ней представлена новая опция для репозиториев — Mount Server. Теперь любой сервер Windows в инфраструктуре Veeam Backup & Replication может стать точкой подключения резервной копии при восстановлении на уровне файлов. А лучшим кандидатом на эту роль будет уже существующий репозиторий под управлением Windows.
При подключении резервной копии к локальному серверу по WAN будут передаваться только команды управления. Файлы восстановятся напрямую, без передачи за пределы площадки.
Еще одна важная новинка в версии 9 — автономная консоль. Эту возможность наши заказчики ждали давно. Консоль позволяет управлять сервером резервного копирования по сети и может устанавливаться удаленно, например, на машине администратора. Вам больше не нужно использовать средства удаленного доступа и ждать своей очереди, чтобы подключиться к серверу резервного копирования. Каждый оператор сможет использовать собственную удаленную консоль. Помимо этого, автономная консоль служит локальной точкой подключения резервных копий при восстановлении, например, с помощью Veeam Explorers. Это очень полезная возможность для удаленных офисов и филиалов.
Но у нас есть и еще кое-что! Как вы могли заметить по версии 8, мы задались целью обеспечить лучшую поддержку ленточных накопителей для компаний любого масштаба. Версия 9 включает новые возможности работы с лентой, которые особенно оценят корпоративные заказчики. Таких возможностей будет довольно много, поэтому я назову только самые значительные.
На мой взгляд, самое важное — это возможность создания общего пула носителей из разных физических библиотек (Media Pool). Даже если носители находятся в разных библиотеках, вы все равно можете объединить их в один пул. Выбрав такой «глобальный пул носителей» в качестве целевого устройства для резервного копирования, вы улучшите производительность и повысите управляемость бэкапа.
Если во время резервного копирования произойдет сбой или одна из библиотек станет недоступна, задача переключится на другую библиотеку или накопитель в соответствии с заданным порядком фейловера. Представьте, что в библиотеке закончились свободные кассеты или заняты все приводы. При использовании глобального пула задание сможет переключиться на другую библиотеку — со свободными кассетами или приводами.
И это еще не все улучшения в работе с лентами. Одна из самых ожидаемых опций в запросах от наших заказчиков — это параллельная работа с несколькими ленточными устройствами. В v9 эта возможность наконец появится. Раньше для одновременной работы с несколькими ленточными устройствами необходимо было создавать различные пулы носителей и задания бэкапа. Теперь параллельная запись на ленту доступна сразу.
Эта простая, но эффективная возможность позволяет выполнять одновременно несколько заданий с одним пулом носителей, или создавать резервные копии сразу на нескольких устройствах.
Пару слов о ротации носителей. Наверняка многие из вас обрадуются, узнав о еще одной новинке v9 — выделенном пуле носителей GFS (Grandfather – Father – Son) для полных резервных копий. В v8 можно было добиться похожего результата, используя несколько пулов, но в v9 все намного проще.
Концепция Grandfather – Father – Son (GFS) не изменилась по сравнению с версией 8. При использовании пула GFS для полных бэкапов кассеты будут храниться в соответствии со схемой — несколько недель, месяцев, кварталов или даже лет. Как и предписывает ваша политика хранения.
С помощью пула GFS можно хранить данные дольше, используя при этом меньшее количество кассет. Например, схема ротации GFS для хранения полных резервных копий за 4 года потребует всего 19 кассет: 4 для еженедельных копий, 12 — для ежемесячных и 3 — для ежегодных. Для краткосрочного хранения полных копий, а также для хранения инкрементальных бэкапов можно использовать обычные пулы носителей. В каждом конкретном случае вы сможете выбрать наиболее подходящий вариант.
Итак, как вы могли убедиться, v9 содержит много новых возможностей для крупных компаний. И это только начало — самое интересное мы оставили на десерт. Мы очень внимательно относимся к потребностям наших корпоративных заказчиков. Поэтому представляем готовое решение для инфраструктуры любого масштаба, возможности которого помогут с легкостью обеспечить доступность данных в вашей компании.
