Не сама VirtualLab - камень преткновения, а неправильная настройка сети.
Для каждой новой изолированной сети прописываем ip адрес маршрутизатора из соответствующей продуктивной сети.
Вот несколько скриншотов с ошибками (кликабельно):
Whitepaper на тему (англ.): http://www.veeam.com/kb2047
Статья на хабре (рус.): http://habrahabr.ru/company/veeam/blog/162201/
Видео (англ.): http://www.veeam.com/videos/surebackup-how-it-works-22.html
P.S. вот такой деньрожденческий пост :)
Потому решил обратить внимание на появившийся документ на сайте Veeam: http://www.veeam.com/kb2047. Там все достаточно подробно описано, как правильно настроить. Как вы думаете, имеет смысл перевести его на русский?
Добавлю немного от себя.
Почему вначале стоит сделать Application Group, а потом настраивать саму виртуальную лабораторию? AG не обязательна, но она определяет последовательность запуска ВМ, составляющих единый сервис (об этом говорится в статье).
Если вы возьмете за правило вначале создавать AG, то потом проще решить, как настроить VL. Например, создаем AG, в которой есть три сервера: DC, SQL и Web. Смотрим, что там с сетями для этих ВМ. Допустим DC расположен в сети α, а SQL и Web в сети β. Значит, нам в VL необходимо сделать две изолированные среды одна из которых будет соответствовать сети α, а вторая - β. Если уже есть созданная VL, то можно туда добавить недостающую изолированную сеть.
И не забудьте затем в VirtualLab включить галку маршрутизировать трафик между изолированными сетями, если у вас сервис распределен по подсетям.
Таймауты - задержи в проверочных скриптах. Про них все хорошо написано в статье. Обратите внимание, что таймаута два: загрузка ОС и загрузка приложения. Первая - это максимальное время ожидания по работе одного из алгоритмов: Stabilization by IP, Stabilization by heartbeat, Stabilization by Maximum allowed boot time (про них в хелпе: http://helpcenter.veeam.com/backup/80/vsphere/index.html?surebackup_job_processing.html). Т.о. если VBR сервер решит, что ОС загрузилась и перезагрузки ВМ не ожидается - проверяется Heartbeat и ping. Затем идет задержка точно по времени указанным во втором значении таймаута.
Почему ВМ перегружается во время загрузки? Если это доменный контроллер - то ему нужно войти в режим авторитетного восстановления.
Еще часто замечал, что при загрузки ВМ она начинает устанавливать обновления, что сказывается на времени ее загрузки и приводит перезагрузке. Не забывайте периодически перегружать продуктивную ВМ, а то она в резервной копии так и будет находится в состоянии ожидания установки обновлений.
Тут еще стоит обратить внимание на цели задания SureBackup. Задание SB используется для загрузки ВМ из резервной копии в изолированной среде VL. Но целей такой загрузки может быть две: проверка работоспособности ВМ (что с бэкапом все в порядке) и создание тестовой среды (восстановление объектов любых приложений, ручное тестирование, разработка, работа с изменениями/обновлениями, обучение и т.п.). В первом случае - скрипты проверки нужны само собой, и такое задание стоит поставить запускаться по расписанию. Во втором случае проверка будет замедлять развертывание тестовой среды, при этом проверка может быть и не нужна вовсе.
Потому для работы с обоими вариантами имеет смысл создать несколько различных заданий SB и AG - одни для тестирования резервных копий, другие для развертывания тестовой среды, и для последних не включать проверки и уменьшить таймауты. А также для второго варианта в SB ставьте галку не выключать AG после загрузки.
Настройка сети VirtalLab. Вот тут самое основное недопонимание, и, соответственно, ошибки при настройке. Потому обращу особое внимание на этом.
Вся настройка сетей крутится вокруг создаваемого сетевого прокси.
На этапе Proxy Settings просто создается подключение в продуктивную среду. Если во время запуска SB вы видите, что ВМ загрузилась, а при этом по таймауту вы получили ошибку типа "ВМ не загрузилась за отведенное время" или сам прокси не загрузился за необходимое время - чаще всего проблема в том, что нет доступа от сервера VBR до сетевого прокси.
Лучше всего и проще сетевой прокси подключать в ту же сеть, что и сервер VBR. Если по каким-то причинам это невозможно, и между VBR и прокси появился маршрутизатор, то на этом промежуточном маршрутизаторе необходимо указать маршрут в маскарадную сеть, находящийся за нашим сетевым прокси.
На этапе Isolated Networks идет просто сопоставление сети продуктивной и создаваемой изолированной. Вот тут и пригодятся знания тех ВМ, которые вы собираетесь запускать в изолированной среде. После создания AG вы уже знаете какие ВМ будут запускаться, просмотрите и составьте список всех сетей (vSwitch), в которых данные ВМ присутствуют и именно для них и создавайте изолированные сети. О чем я и писал выше про AG.
Когда VBR будет запускать ВМ он будет смотреть какие сетевые интерфейсы (vNIC) у каждой ВМ есть и в какие сети (vSwitch) эти интерфейсы подключены. Далее VBR смотрит, если ли для данной сети в настройках VL сопоставление с изолированной сетью, и если такое сопоставление есть - значит в эту определенную изолированную сеть и будет подключен данный интерфейс vNIC ВМ.
Заметьте здесь про ip-пространство сетей пока речи не было. Все на уровне сеть α и соответствующая ей изолированная сеть α'.
Что будет, если у ВМ несколько интерфейсов, и не для всех из них есть изолированный vSwitch? Значит такой интерфейс не будет никуда подключен. Если все интерфейсы ВМ никуда не подключены - значит машина проверки не пройдет и не будет доступна по сети. Если только часть сетевых интерфейсов не подключено - тут могут быть варианты - все зависит от того как работает само приложение внутри ВМ, и сможет ли оно заработать и пройти проверку. Это я к тому, что иногда необязательно все интерфейсы включать в сеть.
Network Settings - там где чаще всего делаются ошибки. Здесь мы делаем подключения нашего сетевого прокси в каждую изолированную сеть, определенную на предыдущем этапе (Isolated Networks). Для каждой сети (vSwitch) необходимо указать правильные настройки vNIC сетевого прокси. Скорее всего вам надо будет зайти и все исправить.
Давайте посмотрим на настройку:
Первое - изолированная сеть - та сеть для которой и делаем настройку. Тут особо и сказать нечего.
IP и маска. Вот тут частая проблема в настройках - указывают не тот адрес, что нужно. В подсказке прямо сказано: указывайте ip адрес маршрутизатора из соответствующей продуктивной сети. Т.е. если ВМ DC подключена к сети α, то здесь нам нужно указать маршрутизатор из сети α, и соответственно маску для сети α.
Маскарадная сеть - обычно выбирается из тех, что не существуют в сети компании.
Что мы видим?
1. У нас есть Veeam Backup, который сидит в своей подсети на виртуальном коммутаторе (vSwitch) под названием "vsw99".
2. Доменный контроллер DC подключен к vSwitch "vsw01".
3. ВМ с SQL имеет два интерфейса: один в сети "vsw05", второй в сети "vsw10".
4. ВМ Web находится в одной сети с SQL - "vsw05".
I) Строим Application Group, где пропишем порядок загрузки ВМ DC, SQL и Web. Установим нужные тайм-ауты и проверки, если необходимо.
II) Создаем VirtualLab, где
a) на закладке Proxy Settings указываем:
1. vSwitch, куда мы подключаем - тот же, что и Veeam Backup сервер. Так проще - не надо будет настраивать промежуточные маршрутизаторы/коммутаторы.
И не забудьте затем в VirtualLab включить галку маршрутизировать трафик между изолированными сетями, если у вас сервис распределен по подсетям.
Таймауты - задержи в проверочных скриптах. Про них все хорошо написано в статье. Обратите внимание, что таймаута два: загрузка ОС и загрузка приложения. Первая - это максимальное время ожидания по работе одного из алгоритмов: Stabilization by IP, Stabilization by heartbeat, Stabilization by Maximum allowed boot time (про них в хелпе: http://helpcenter.veeam.com/backup/80/vsphere/index.html?surebackup_job_processing.html). Т.о. если VBR сервер решит, что ОС загрузилась и перезагрузки ВМ не ожидается - проверяется Heartbeat и ping. Затем идет задержка точно по времени указанным во втором значении таймаута.
Почему ВМ перегружается во время загрузки? Если это доменный контроллер - то ему нужно войти в режим авторитетного восстановления.
Еще часто замечал, что при загрузки ВМ она начинает устанавливать обновления, что сказывается на времени ее загрузки и приводит перезагрузке. Не забывайте периодически перегружать продуктивную ВМ, а то она в резервной копии так и будет находится в состоянии ожидания установки обновлений.
Тут еще стоит обратить внимание на цели задания SureBackup. Задание SB используется для загрузки ВМ из резервной копии в изолированной среде VL. Но целей такой загрузки может быть две: проверка работоспособности ВМ (что с бэкапом все в порядке) и создание тестовой среды (восстановление объектов любых приложений, ручное тестирование, разработка, работа с изменениями/обновлениями, обучение и т.п.). В первом случае - скрипты проверки нужны само собой, и такое задание стоит поставить запускаться по расписанию. Во втором случае проверка будет замедлять развертывание тестовой среды, при этом проверка может быть и не нужна вовсе.
Потому для работы с обоими вариантами имеет смысл создать несколько различных заданий SB и AG - одни для тестирования резервных копий, другие для развертывания тестовой среды, и для последних не включать проверки и уменьшить таймауты. А также для второго варианта в SB ставьте галку не выключать AG после загрузки.
Настройка сети VirtalLab. Вот тут самое основное недопонимание, и, соответственно, ошибки при настройке. Потому обращу особое внимание на этом.
Вся настройка сетей крутится вокруг создаваемого сетевого прокси.
На этапе Proxy Settings просто создается подключение в продуктивную среду. Если во время запуска SB вы видите, что ВМ загрузилась, а при этом по таймауту вы получили ошибку типа "ВМ не загрузилась за отведенное время" или сам прокси не загрузился за необходимое время - чаще всего проблема в том, что нет доступа от сервера VBR до сетевого прокси.
Лучше всего и проще сетевой прокси подключать в ту же сеть, что и сервер VBR. Если по каким-то причинам это невозможно, и между VBR и прокси появился маршрутизатор, то на этом промежуточном маршрутизаторе необходимо указать маршрут в маскарадную сеть, находящийся за нашим сетевым прокси.
На этапе Isolated Networks идет просто сопоставление сети продуктивной и создаваемой изолированной. Вот тут и пригодятся знания тех ВМ, которые вы собираетесь запускать в изолированной среде. После создания AG вы уже знаете какие ВМ будут запускаться, просмотрите и составьте список всех сетей (vSwitch), в которых данные ВМ присутствуют и именно для них и создавайте изолированные сети. О чем я и писал выше про AG.
Когда VBR будет запускать ВМ он будет смотреть какие сетевые интерфейсы (vNIC) у каждой ВМ есть и в какие сети (vSwitch) эти интерфейсы подключены. Далее VBR смотрит, если ли для данной сети в настройках VL сопоставление с изолированной сетью, и если такое сопоставление есть - значит в эту определенную изолированную сеть и будет подключен данный интерфейс vNIC ВМ.
Заметьте здесь про ip-пространство сетей пока речи не было. Все на уровне сеть α и соответствующая ей изолированная сеть α'.
Что будет, если у ВМ несколько интерфейсов, и не для всех из них есть изолированный vSwitch? Значит такой интерфейс не будет никуда подключен. Если все интерфейсы ВМ никуда не подключены - значит машина проверки не пройдет и не будет доступна по сети. Если только часть сетевых интерфейсов не подключено - тут могут быть варианты - все зависит от того как работает само приложение внутри ВМ, и сможет ли оно заработать и пройти проверку. Это я к тому, что иногда необязательно все интерфейсы включать в сеть.
Network Settings - там где чаще всего делаются ошибки. Здесь мы делаем подключения нашего сетевого прокси в каждую изолированную сеть, определенную на предыдущем этапе (Isolated Networks). Для каждой сети (vSwitch) необходимо указать правильные настройки vNIC сетевого прокси. Скорее всего вам надо будет зайти и все исправить.
Давайте посмотрим на настройку:
IP и маска. Вот тут частая проблема в настройках - указывают не тот адрес, что нужно. В подсказке прямо сказано: указывайте ip адрес маршрутизатора из соответствующей продуктивной сети. Т.е. если ВМ DC подключена к сети α, то здесь нам нужно указать маршрутизатор из сети α, и соответственно маску для сети α.
Маскарадная сеть - обычно выбирается из тех, что не существуют в сети компании.
Для наглядности давайте разберем пример.
Допустим у нас есть такие ВМ:| ВМ | vNIC | vSwitch | ip | mask | gw |
| VBR | vNIC1 | vsw99 | 10.10.10.100 | 255.255.255.0 | 10.10.10.1 |
| DC | vNIC1 | vsw01 | 10.100.10.4 | 255.255.255.0 | 10.100.10.254 |
| SQL | vNIC1 | vsw05 | 10.100.50.66 | 255.255.255.0 | 10.100.50.1 |
| vNIC2 | vsw10 | 10.50.100.66 | 255.255.255.0 | 10.50.100.1 | |
| Web | vNIC1 | vsw05 | 10.100.50.18 | 255.255.255.0 | 10.100.50.1 |
1. У нас есть Veeam Backup, который сидит в своей подсети на виртуальном коммутаторе (vSwitch) под названием "vsw99".
2. Доменный контроллер DC подключен к vSwitch "vsw01".
3. ВМ с SQL имеет два интерфейса: один в сети "vsw05", второй в сети "vsw10".
4. ВМ Web находится в одной сети с SQL - "vsw05".
I) Строим Application Group, где пропишем порядок загрузки ВМ DC, SQL и Web. Установим нужные тайм-ауты и проверки, если необходимо.
II) Создаем VirtualLab, где
a) на закладке Proxy Settings указываем:
| vSwitch | ip | mask | gw |
| vsw99 | 10.10.10.101 | 255.255.255.0 | 10.10.10.1 |
2. Адрес статически или динамический и той же сети, что и сам VBR,
b) на закладке Isolated Networks делаем сопоставлении сетей продуктивных и создаваемых изолированных.
| Продуктивная | Изолированная |
| vsw01 | Vitual Lab vsw01 |
| vsw05 | Vitual Lab vsw05 |
Обратите внимание сети нам нужно две: одну для DC, вторую для SQL+Web. Изолированная сеть для "vsw99" будет создано автоматически, но нам она не нужна - потому ее удалим. Сеть "vsw10" явно какая-то служебная и для работы ВМ SQL ненужна в случае этого моего конкретного примера, потому ее не создаем. Если в процессе запуска ВМ SQL выяснится, что без работающей сети ВМ не работает, то надо будет ее создать и перезапустить задание SureBackup.
c) на закладке Network Settings прописываем настройки изолированных сетей:
| vNIC | vSwitch | ip | mask | Masquarade |
| vNIC1 | Vitual Lab vsw01 | 10.100.10.254 | 255.255.255.0 | 10.255.255.0 |
| vNIC2 | Vitual Lab vsw05 | 10.100.50.1 | 255.255.255.0 | 10.255.254.0 |
Понятно? Напишите в комментариях или мне на почту обязательно, если нужно еще подробнее разъяснить.
Вот несколько скриншотов с ошибками (кликабельно):
 |
| Сетевой прокси (на закладке Proxy Settings) подключен так, что Veeam Backup сервер не может достучаться до прокси |
 |
| IP адрес сетевой прокси (на закладке Network Settings) указан неправильно: скорее всего адрес не соответствует сети ВМ. |
 |
| В виртуальной лаборатории не сети, которой должна быть подключена ВМ. На закладке Isolated Networks надо добавить нужную сеть. Обратите внимание, что тесты heartbeat пройдены, а тесты ping и далее пропущены (Skipped). |
Ссылки по теме:
В моем блоге про SureBackup и VirtualLab (рус.): http://www.veskin.ru/search/label/SureBackupWhitepaper на тему (англ.): http://www.veeam.com/kb2047
Статья на хабре (рус.): http://habrahabr.ru/company/veeam/blog/162201/
Видео (англ.): http://www.veeam.com/videos/surebackup-how-it-works-22.html
P.S. вот такой деньрожденческий пост :)
Комментариев нет:
Отправить комментарий