Ожидаемый в этом году Veeam Availability Suite v9 содержит ряд новых возможностей для крупных компаний. В подобных организациях часто возникают трудности с масштабируемостью и управлением удаленными офисами и филиалами (ROBO).

Одной из сильных сторон наших решений является собственная технология взаимодействия с гостевыми ОС виртуальных машин, которая гарантирует корректное резервное копирование и восстановление. Veeam не использует постоянно действующие агенты внутри виртуальных машин. При старте бэкап-задания на каждой виртуальной машине с включенной опцией "Application Aware Image Processing" запускается специальный временный модуль. Это происходит автоматически, и по окончании резервного копирования модуль удаляется. Процесс, который запускается на ВМ, координирует работу VSS и обеспечивает выполнение необходимых шагов для каждого поддерживаемого приложения, включая усечение журнала транзакций и индексацию гостевой файловой системы.

В предыдущих версиях взаимодействие с гостевыми ОС осуществлял сервер резервного копирования. Именно центральная консоль отвечала за установку временного модуля на каждую ВМ (по сети или с помощью VIX API). Такой механизм всегда отлично работал, но по мере увеличения размеров и сложности среды появилось два ограничения.

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

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

1

Можно разместить в удаленном офисе репозиторий и прокси-сервер резервного копирования — тогда данные ВМ при бэкапе и восстановлении не будут покидать пределы площадки. Однако для взаимодействия сервера резервного копирования с гостевыми ОС все равно придется использовать WAN. Это тоже приведет к проблемам с масштабируемостью.

Для решения этих проблем в v9 представлен Guest Interaction Proxy — прокси-сервер для взаимодействия с гостевыми ОС. Роль Guest Interaction Proxy может выполнять любой сервер под управлением Microsoft Windows (в том числе, существующий прокси-сервер или репозиторий). Идеальным вариантом будет прокси-сервер, так как он обычно находится ближе всего к виртуальным машинам.

2

Если разместить Guest Interaction Proxy на удаленной площадке, то по WAN будут передаваться только команды управления от сервера резервного копирования. Именно Guest Interaction Proxy будет устанавливать временный модуль на ВМ и управлять взаимодействием с гостевыми ОС. Таким образом, объем WAN-трафика и нагрузка на сервер бэкапа снизятся. Поскольку один сервер резервного копирования может контролировать сразу несколько Guest Interaction Proxy, масштабируемость значительно возрастет. Например, представьте себе компанию с 500 удаленными площадками. На каждой площадке можно развернуть прокси-сервер и назначить ему роль Guest Interaction Proxy. Контролировать все эти машины будет сервер резервного копирования. Для улучшения взаимодействия с большим количеством ВМ можно развернуть несколько Guest Interaction Proxy в пределах одного крупного дата-центра.

У технологии есть еще одно малозаметное преимущество — доступ к гостевой ОС при невозможности использования VIX API. Например, если учетная запись для взаимодействия с ВМ не может быть использована из соображений безопасности. В таком случае вы можете использовать компьютер под управлением Windows с двумя сетевыми интерфейсами — в производственной сети и в сети резервного копирования. В качестве Guest Interaction Proxy компьютер будет "пересылать" трафик от сервера резервного копирования в производственную сеть.

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

3

Если репозиторий расположен локально, данные все равно будут дважды передаваться по сети WAN — сначала на сервер резервного копирования, а потом обратно на удаленную площадку, для восстановления. Можно попробовать обойти WAN — например, использовать мастер для восстановления файлов (FLR wizard) и соответствующую программу. Но у этого метода тоже есть свои недостатки.

С версией 9 вам не придется искать обходные пути, ведь в ней представлена новая опция для репозиториев — Mount Server. Теперь любой сервер Windows в инфраструктуре Veeam Backup & Replication может стать точкой подключения резервной копии при восстановлении на уровне файлов. А лучшим кандидатом на эту роль будет уже существующий репозиторий под управлением Windows.

4

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

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

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

На мой взгляд, самое важное — это возможность создания общего пула носителей из разных физических библиотек (Media Pool). Даже если носители находятся в разных библиотеках, вы все равно можете объединить их в один пул. Выбрав такой "глобальный пул носителей" в качестве целевого устройства для резервного копирования, вы улучшите производительность и повысите управляемость бэкапа.

5

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

И это еще не все улучшения в работе с лентами. Одна из самых ожидаемых опций в запросах от наших заказчиков — это параллельная работа с несколькими ленточными устройствами. В v9 эта возможность наконец появится. Раньше для одновременной работы с несколькими ленточными устройствами необходимо было создавать различные пулы носителей и задания бэкапа. Теперь параллельная запись на ленту доступна сразу.

6

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

Пару слов о ротации носителей. Наверняка многие из вас обрадуются, узнав о еще одной новинке v9 — выделенном пуле носителей GFS (Grandfather – Father – Son) для полных резервных копий. В v8 можно было добиться похожего результата, используя несколько пулов, но в v9 все намного проще.

Концепция Grandfather – Father – Son (GFS) не изменилась по сравнению с версией 8. При использовании пула GFS для полных бэкапов кассеты будут храниться в соответствии со схемой — несколько недель, месяцев, кварталов или даже лет. Как и предписывает ваша политика хранения.

С помощью пула GFS можно хранить данные дольше, используя при этом меньшее количество кассет. Например, схема ротации GFS для хранения полных резервных копий за 4 года потребует всего 19 кассет: 4 для еженедельных копий, 12 — для ежемесячных и 3 — для ежегодных. Для краткосрочного хранения полных копий, а также для хранения инкрементальных бэкапов можно использовать обычные пулы носителей. В каждом конкретном случае вы сможете выбрать наиболее подходящий вариант.

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

GD Star Rating
loading...
Новые возможности v9 для крупных компаний: улучшенная поддержка ROBO и бэкапа на ленточные накопители, 5.0 out of 5 based on 2 ratings