среда, 16 февраля 2011 г.

Автоматизируем проверку резервных копий машин с помощью Veeam SureBackup

Продолжая знакомиться с Veeam Backup & Replication, я занялся изучением функции SureBackup, позволяющей проводить автоматическое тестирование резервных копий виртуальных машин.

Наш коллега, Владимир Ескин, выложил в своем блоге отличное видео, описывающее процедуру настройки SureBackup в Veeam Backup & Replication. Поэтому, если вы еще не работали с данным продуктом, настоятельно рекомендую посмотреть его.

Каким же образом работает SureBackup?

Veeam Backup & Replication позволяет разворачивать и запускать образы виртуальных машин прямо из резервной копии в изолированной от остальной части инфраструктуры среде - виртуальной лаборатории (Virtual Lab). Каждая виртуальная лаборатория определяется набором изолированных сетей - виртуальных свитчей и групп портов, не имеющих связь с физическими сетями. При создании виртуальной лаборатории администратор выбирает один или несколько узлов ESX, на которых требуется разворачивать виртуальные машины, хранилище для временных файлов и настройки подсетей.

Перечень виртуальных машин, которые требуется протестировать задается на уровне группы приложений (Application Group). В простейшем случае группа может содержать одну единственную проверяемую машину, однако, в большинстве случаев для проверки серверов приложений (например, почтового или web-сервера) должны быть развернуты инфраструктурные службы (например, DNS, служба каталога, СУБД). В группе определяется порядок запуска ВМ и тесты, которые необходимо использовать для проверки каждой из них.

По умолчанию, в Veeam Backup & Replication есть несколько предустановленных тестовых наборов, называемых ролями (Server Roles). При создании группы приложений администратор может назначить для виртуальной машины одну из ролей, определив тем самым, какие тесты будут проводиться. Каждая роль хранится в отдельном файле в формате .xml в папке '%ProgramFiles%\Veeam\Backup and Replication\SbRoles' и может быть изменена по усмотрению администратора.

На выбор доступны следующие методы проверки работы ВМ:

  • Прием Heartbeat сигнала от агента VMware Tools, установленного в ВМ.
  • Отправка эхо запроса (Ping) на сетевой адрес виртуальной машины
  • Запуск сценариев для проверки работы.
И если с Heartbeat все понятно, то два других варианта требуют дополнительных пояснений.

Каким образом серверу Veeam удается пинговать виртуальную машину в изолированной сети?

Доступ к изолированной сети осуществляется через специальную виртуальную машин - прокси сервер, которая автоматически создается для каждой виртуальной лаборатории. Один из интерфейсов прокси сервера подключается к производственной сети, другой - к изолированной. Если производственная инфраструктура включает в себя несколько подсетей, то прокси сервер также выполняет функции маршрутизатора между изолированными подсетями, назначая себе, как правило, первый адрес в каждой из подсетей.
Для избежания конфликта с адресацией (поскольку и в производственной сети и в изолированной используется одинаковый диапазон адресов) используются так называемые маскарадные сети (masquerade network). Для каждой IP адреса узла в изолированной сети ставится в соответствие аналогичный IP адрес в маскарадной сети (например 192.168.1.0/24 -> 192.168.254.0/24). В момент запуска виртуальной лаборатории на сервере Veeam Backup прописывается статический маршрут к маскарадной сети, в котором в качестве маршрутизатора указывается адрес прокси сервера.

Таким образом, когда серверу Veeam требуется получить доступ к тестируемой виртуальной машине, то вместо ее адреса в производственной сети, указывается аналогичный адрес из маскарадной сети (например 192.168.1.36 -> 192.168.254.36). По таблице маршрутизации пакет отправляется на прокси сервер.

Прокси сервер выступает в роли NAT устройства, и подменяет в принятом пакете адрес отправителя на свой собственный адрес в изолированной сети (в данном примере - 192.168.1.1), а также подменяет адрес назначения с маскарадной подсети (192.168.254.0) на адрес производственной подсети (192.168.1.0) и отправляет пакет получателю в изолированной подсети.

Таким образом, производственная сеть и тестовая сеть оказываются достаточно эффективно разделены, но сервер Veeam Backup не теряет возможности сетевого взаимодействия с тестируемыми машинами.

Наконец, Veeam Backup позволяет запускать сценарии для проверки ВМ. Для всех предустановленных ролей используется один единственный сценарий 'VmConnectionTester.exe' - этакий упрощенный аналог Telnet, принимающий в качестве аргументов IP адрес сервера и порт TCP, по которому следует проверить. Здесь важно сделать небольшое отступление и сказать, что Veeam Backup считает сценарий успешно отработавшим, если он был завершен с кодом возврата 0 и неуспешно - при любом другом.

Администратор может самостоятельно указывать любые произвольные сценарии (поддерживает запуск .exe, .bat, .cmd, .js, .vbs, .wsf). Все сценарии запускаются из-под учетной записи настроенной для запуска служб Veeam Backup & Replication.

В принципе, использование VmConenctionTester позволяют проверить доступность большинства сетевых служб в виртуальной машине. Однако, существуют службы, которые не используют для работы протокол TCP, предназначены для работы в качестве клиентских служб или выполняются локально. Для проверки таких служб может использоваться следующий сценарий (query-service.ps1) на powershell, проверяющий, что служба на удаленном компьютере запущена:

#query-service.ps1
param(
[string] $ip, #IP address of checked server
[string] $service ) #Service name
$result = (get-Service -ComputerName $ip -Name $service -ErrorAction SilentlyContinue)
if($result.status -eq "Running")
{
exit
}
else
{
write-host ("Error 1, Service '" + $service + "' not running or not found.") #if service not found or not running, then echo
$host.SetShouldExit(1)
exit
}
В качестве входных параметров сценарий принимает IP адрес сервера и имя службы.

Если служба не запущена или такой службы не существует, сценарий завершается и передает код ошибки 1 обработчику Veeam Backup.

Для работы сценария требуется соблюдение следующих условий:

Во-первых, требуется разрешить запуск сценариев .ps1 на сервере Veeam Backup. Сделать это можно, выполнив в консоли Powershell команду:
set-executionpolicy remotesigned

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

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

Поскольку Veeam Backup не поддерживает запуск .ps1 сценариев напрямую, можно использовать оболочку в виде batch файла (query-service.bat):

REM query-service.bat
@ECHO OFF
powershell.exe -noninteractive -noprofile -command "& {C:\Temp\query-service.ps1 %1 %2 }"
EXIT /B %errorlevel%
Теперь требуется сохранить оба файла в любую папку на сервере (по умолчанию я использовал 'C:\Temp\') и отредактировать одну из групп приложений, добавить скрипт, указать путь к сценарию query-service.bat в поле Path и указав в качестве аргументов IP адрес (задается переменной %vm_ip%) и имя службы. В данном примере в качестве проверяемой службы выбран DHCP клиент.

Теперь, при успешной отработке сценария, если служба запущена, виртуальная машина успешно пройдет проверку.

Если же, по какой-то причине, служба не будет запущена, Veeam Backup также уведомит об этом и автоматически завершит работу виртуальной лаборатории.

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

понедельник, 14 февраля 2011 г.

Баг Veeam SureBackup - 'DestinationHostUnreachable'

Постигая азы использования Veeam Backup & Replication, я натолкнулся на неприятный баг, связанный с функцией проверки резервных копий - Veeam SureBackup.


Администраторам, работавшим с данным продуктом, должно быть известно, что для SureBackup требуется создать виртуальную лабораторию (Virtual Lab) и настроить одну или несколько изолированных сетей, в которых будут запускаться и тестироваться резервные копии виртуальных машин. Проблема заключается в том, что вы можете встретить ошибку 'DestinationHostUnreachable' при попытке прокси сервера пропинговать IP адрес тестируемой виртуальной машины.


При этом, казалось бы, все должно быть настроено правильно - брандмауэр в виртуально машине не блокирует ICMP трафик, более того, если настроить static mapping адрес для виртуальной машины, то она будет прекрасно пинговаться.

Проблема, как оказалось, заключается в некорректной длине маски, которую по умолчанию задает мастер на этапе настройки vNic для прокси сервера для изолированных сетей. В данном примере, в качестве рабочей подсети используется 192.168.1.0 с маской 255.255.255.0.

Что интересно - если вручную указать неправильные настройки и попробовать применить их, то появится следующее предупреждение.

Для решения проблемы требуется прописать маску правильной длины.

После этого пинг должен заработать.

Проблема актуальна для версии Veeam Backup & Replication 5.0.1.198.

понедельник, 24 января 2011 г.

Видео: Резервное копирование виртуальных машин VMware vSphere 4.x с помощью Symantec Backup Exec 2010 R2 (часть III)

Заключительная часть видеообзора возможностей Symantec Backup Exec 2010 R2 по резервному копированию и восстановлению виртуальных машин VMware vSphere.



понедельник, 17 января 2011 г.

Видео: Резервное копирование виртуальных машин VMware vSphere 4.x с помощью Symantec Backup Exec 2010 R2 (часть II)

Как и обещал, выкладываю продолжение видео по резервному копированию виртуальных машин VMware с помощью Symantec Backup Exec 2010 R2.

На этот раз мы рассмотрим процедуру восстановления виртуальных машин из резервной копии и настройку резервного копирования данных приложений внутри виртуальной машины.

Всем приятного просмотра.


пятница, 14 января 2011 г.

Видео: Резервное копирование виртуальных машин VMware vSphere 4.x с помощью Symantec Backup Exec 2010 R2

Уже давно в голове у меня витала идея о создании видео обзоров по тому или иному продукту. Поэтому сегодня Ваш покорный слуга решил представить общему вниманию небольшой ролик, описывающий установку и первоначальную настройку сервера резервного копирования Symantec Backup Exec 2010 R2 применительно к VMware vSphere 4.1. Если, что называется, 'попрет', в ближайшем будущем обещаю выложить продолжение, и, наверняка, не только по Symantec.

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

И, конечно, замечания и пожелания крайне приветствуются.


понедельник, 20 декабря 2010 г.

История о подключении FC Tape Library к VMware ESXi

Внимание: перед тем, как выполнять рекомендации, приведенные в статье, прочтите данное сообщение. Проброс ленточной библиотеки внутрь виртуальных машин НЕ поддерживается VMware и НЕ является приемлемым решением для организации резервного копирования виртуальной среды. Я настоятельно рекомендую рассмотреть альтернативные варианты решения задачи, например, установить FC HBA адаптер в любой доступный физический сервер и подключить к нему ленточную библиотеку. Это избавит вас от множества проблем, связанных с настройкой проброса библиотеки внутрь ВМ и дальнейшей эксплуатацией данного решения. В особенности, когда вам потребуется что-то восстановить из резервной копии.

Обновление: начиная с vSphere 5.0, VMware перестала поддерживать подключение ленточных приводов (библиотек) к хостам ESXi в том числе по SAS/SCSI интерфейсу (https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-50-release-notes.html): 
Tape drives. VMware does not support tape drives that are connected to ESX/ESXi hosts. For additional information, see Knowledge Base article 1016407.

Недавно у одного из заказчиков появилась необходимость подключить ленточную библиотеку HP StorageWorks MSL2024 G3 к серверу резервного копирования, расположенному внутри виртуальной машины, работающей под управлением VMware ESXi 4.1.

До этого момента я несколько раз встречал сообщения о возможных проблемах при использовании ленточных библиотек в виртуальной среде, но руководство Fibre Channel SAN Configuration Guide окончательно развеяло мои сомнения:

"ESX/ESXi does not support FC connected tape devices"

Памятуя о том, что "unsupported" далеко не всегда равняется "not working", и учитывая, что библиотека уже была приобретена заказчиком, было принято решение попробовать ее подключить.

Небольшое отступление - не то, чтобы я был ярым противником использования не поддерживаемых решений, но уже не раз убеждался, что соблюдение требований вендоров позволяет избежать большого числа проблем при настройке и дальнейшей эксплуатации системы. Вдобавок, для резервного копирования виртуальной среды гораздо более эффективно использование специализированных решений, вроде VMware Data Recovery или Veeam Backup & Replication, которые не работают с ленточными библиотеками.

Библиотека была смонтирована, подключена к FC свитчу и настроена, в консоли vSphere Client сделан Rescan устройств хранения, после чего было обнаружено одно устройство - стример, автозагрузчик куда-то пропал.


Вкладка Paths немного прояснила ситуацию.


Оба пути, по которым ESXi должен был получить доступ к автозагрузчику, показывались как мертвые (Dead). Проверка коммутации библиотеки b серверов, настроек зон на FC свитче результатов не принесла.

В Интернете удалось найти несколько похожих проблем и определить причину такого поведения. Все дело в некорректной работе ESXi с некоторыми FC устройствами в режиме ALUA (Asymmetric Logical Unit Access). Убедиться в этом можно, открыв журнал событий ESXi (/var/log/messages):


Запуск команды esxcli nmp satp listrules -s VMW_SATP_ALUA позволил получить список всех правил, настроенных на сервере по умолчанию:


В качестве решения проблемы предлагалось удалить лишнее правило, что и было сделано с помощью команды:
esxcli nmp satp deleterule --satp VMW_SATP_ALUA --claim-option tpgs_on

После повторного выполнения Rescan пути чудесным образом ожили и автозагрузчик появился в списке доступных устройств.


Затем оба устройства (стриммер и автозагрузчик) были добавлены в выбранную виртуальную машину. Для этого в свойствах ВМ нужно нажать кнопку Add... и в открывшемся окне в качестве типа устройства выбрать SCSI Device и нужное устройство.


Happy End.

четверг, 9 декабря 2010 г.

Работаем с XenDesktop 5

Недавно очередная, на этот раз уже пятая, версия Citrix XenDesktop показала всем свое новое "лицо".

Программисты Citrix'а сжалились над простыми смертными вроде нас с вами и полностью переработали интерфейс продукта, сделав его более удобным и дружелюбным. Эту работу трудно переоценить, вспоминая то множество оснасток, которыми приходилось ранее управлять в XenDesktop 4 и до сих пор приходится - в XenApp.

Одно из основных нововведений - централизованная консоль управления Citrix Desktop Studio с помощью которой можно назначать виртуальные рабочие станции пользователям, настраивать пользовательские и компьютерные политики, управлять веб-сайтами Citrix.


Для рядовых администраторов и сотрудников технической поддержки пригодится Desktop Director, позволяющий наблюдать за инфраструктурой XenDesktop и выполнять базовые операции с рабочими станциями через веб-браузер.


Каким образом эти нововведения затронули процедуру установки и настройки?

В качестве примера рассмотрим самый простой вариант развертывания VDI инфраструктуры, включающий в себя сервер XenDesktop, рабочую станцию и клиентский компьютер, с которого будет осуществляться подключение. В качестве рабочей станции можно использовать выделенный физический компьютер или виртуальную машину, работающую под управлением любого доступного гипервизора (Citrix XenServer, Microsoft Hyper-V или VMware ESX). В данном примере не предполагается выполнять интеграцию XenDesktop с подсистемой виртуализации для автоматизации развертывания и управления виртуальными машинами, поэтому каждую рабочую станцию, добавляемую в XenDesktop придется устанавливать и настраивать отдельно. Пример схемы развертывания приведен на рисунке.


В качестве ОС, устанавливаемой на серверы, рекомендуется использовать Windows Server 2008 R2, а в качестве клиентской ОС - Windows 7.

Перед началом установки требуется выполнить настройку сети на всех компьютерах и ввести их в домен Active Directory.

Для установки XenDesktop вам понадобится дистрибутив, который можно загрузить с сайта Citrix после прохождения регистрации. В моем случае использовалась Evaluation версия, включающая в себя все необходимые компоненты.

Установка и настройка сервера XenDesktop
Распакуйте XD5_Plat_Single.zip и подмонтируйте образ XenDesktop5.iso к серверу. Запустите установщик и выберите Install XenDesktop.


Примите лицензионное соглашения, выбрав I accept terms and conditions и нажмите Next.


На странице выбора компонентов (Select Components to Install) убедитесь, что выбраны все компоненты и нажмите Next.


На странице Firewall Configuration нажмите Next.

На странице Summary нажмите Install.

Дождитесь окончания установки. На странице Installation Successful убедитесь, что Configure XenDesktop after closing выбрано и нажмите Close.


В открывшейся консоли Citrix Desktop Studio выберите выберите вариант Advanced Configuration.


Укажите имя сайта (Site), путь к файлу лицензий (License file location) и редакцию (Edition). Проверьте, что выбран вариант использования сервер баз данных по умолчанию (Use default database). Нажмите Next.


При добавлении первого сервера система сама предложит создать и настроить подключение к базе. Нажмите OK.


На вкладке Host укажите тип хоста (Host type) - None, нажмите Next.


На вкладке Summary нажмите Finish.


Дождитесь, пока система завершит настройку.

Настройка рабочих станций
Установите Citrix XenDesktop Agent на виртуальной машине или рабочей станции, к которой удаленно будет подключаться пользователь. Запустите установщик, нажмите Install Virtual Desktop Agent.


Выберите вариант Advanced Install.


Если для видеокарты используется WDDM драйвер, то при установке на физический компьютер или виртуальную машину VMware ESX, вы получите сообщение с предложением отключить данный драйвер. Согласитесь, нажав Yes, так как если этого не сделать, то драйвер Citrix System Inc. Display Driver не сможет работать (подробнее об проблеме можно прочитать тут).


На странице Select Components to Install снимите Support for XenApp Application Delivery и нажмите Next.

На странице Controller Location в поле Manually enter controller location(s) введите имя сервера, на котором установлены службы XenDesktop. Нажмите Next.


На странице Virtual Desktop Configuration нажмите Next.


На странице Summary нажмите Install.


Дождитесь завершения установки и нажмите Close, чтобы перезагрузить рабочую станцию.

Откройте консоль Citrix Desktop Studio на сервере, щелкните правой кнопкой мыши по Machines и выберите Create Catalog.


В мастере Create Catalog на странице Machine Type выберите Physical и нажмите Next.


На странице Machines & users с помощью кнопки Add Computers... добавьте из Active Directory учетную запись рабочей станции, которую вы настроили ранее.


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


На странице Administrators нажмите Next.


На странице Summary задайте имя создаваемого каталога (Catalog name) и нажмите Finish для завершения настройки.


Теперь требуется назначить пользователям рабочие станции.

Щелкните правой кнопкой мыши по Assigments и выберите Create Desktop Group.

В мастере Create Desktop Group на странице Catalog выберите ранее созданный каталог, в поле Add machines введите количество машин, которое требуется назначить. Нажмите Next.


На странице Users с помощью кнопки Add... добавьте из Active Directory группы или пользователей, которым следует разрешить подключаться к удаленным рабочим станциям, и нажмите Next.


На странице Delegation нажмите Next.

На странице Summary введите имя, которое будут видеть пользователи при подключении (Display name) и имя группы (Desktop Group name) и нажмите Finish.


Проверка работы XenDesktop
На клиентской машине откройте браузер. В адресной строке впишите имя сервера XenDesktop. При первом входе на сайт вам предложат установить плагин Citrix Online Plugin Web.


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


Если вы все сделали правильно, то вам будет доступен удаленный рабочий стол.


Поздравляю с успешной настройкой.