Вход|Регистрация

Неразборчивое о виртуальном
Записи с меткой Data Recovery

Permission for DataRecovery

Пятница, 11 февраля 2011, 18:56

Не так давно в комьюнити появился вопрос о настройке прав доступа специального пользователя — не администратора для работы с DataRecovery. Подобные вопросы возникали и раньше (например, тут и тут), но лучшее, что там есть — это ссылка на статью VMware Data Recovery fails to connect to vCenter. Цитирую:

You require the following privileges to manage the VDR appliance:

    * Datastore > Allocate space
    * VirtualMachine > Configuration > Add new disk
    * VirtualMachine > Configuration > Change resource
    * VirtualMachine > Configuration > Remove disk
    * VirtualMachine > Configuration > Settings
    * Global > Licenses

Действительно, подключиться пользователем с такими правами можно. Но этого набора прав явно недостаточно даже для проведения операции бекапирования. Задание прерывается с ошибкой ещё на этапе снятия снапшота бекапируемой машины:

Возможно, в статье предполагается, что для взаимодействиея DR и vCenter используется администраторский аккаунт, устанавливаемый единожды и неизвестный для оператора резервного копирования.

Задачу для себя я сформулировал так: выделенный пользователь должен подключаться клиентом под своим аккаунтом и иметь возможность видеть только машины в отдельном пуле ресурсов, которые он может бекапить/восстанавливать. Кроме того возможность его деструктивного взаимодействия со всеми элементами виртуальной инфраструктуры должна быть, по возможности, минимальной. Предполагается, что все защищаемые машины находятся на одном или нескольких датасторах, на которых не могут появиться "посторонние" продуктовые машины.

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

Расположение Permissions для такой роли:

Уровень датацентра (без наследования), хост/хосты, где расположен ресурс-пул с машинами (без наследования), сам ресурс-пул (с наследованием), датастор с машинами (с наследованием), сеть, куда подключены машины (с наследованием).

Расположение Permissions для роли Read-Only:

Хост/хосты, на которых может выполняться виртуальная машина DataRecovery (без наследования) — неочевидный и попивший мне много крови момент! — виртуальная машина DataRecovery (без наследования).

 

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

Написать комментарий

Проблема с Data Recovery

Среда, 22 декабря 2010, 17:49

Для резервного копирования виртуальной инфраструктуры у VMware есть простой продукт Data Recovery. В процессе его внедрения столкнулся с необычной ситуацией.

На закладке Reports около двух 2х часов ночи (в самый разгар операции бекапирования) было сообщение о неожиданном старте сервиса Data Recovery.



Само собой, незаконченные бекапы дальше не пошли и несколько снапшотов дисков ввиртуальных машин так и остались примаплены к машине с DR. Снапшоты применились руками без проблем. Остался вопрос: Почему?

Беглый просмотр логов и событий с vSphere Client не дал намёков на причину проблемы кроме того, что примерно в это время все хосты на 3 секунды уходили в состояние дисконнект (забегая вперёд, такое короткое время реконнекта мне до сих пор не до конца понятно).

Следующим подозреваемым была ProCurve, куда включены все хосты, но там всё OK.

В логах хоста, на котором работала вм с DR тоже всё отлично.

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

В конечном этоге, виновником оказалась локальная служба обновления Windows, где работал vCenter. Система модернизировалась из некого рабочего состояния, потому во внутреннюю логику работы гостевых ОС я почти не вмешивался. В разрешённое время (02:00) она выкачала пачку свежих обновленийи и корректно перегрузила вм. Потому vCenter воспринял это как плановую перезагрузку, а вот DR такого поворота судьбы не ожидала и, видимо, после какого-то обращения к недоступному vCenter, выпала в осадок и перезапузилась.

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

 

UPD: по моим наблюдениям чаще всего виндовым админам приходится начинать администрировать виртуальную инфраструктуру от VMware. Так вот для тех, кто не любит копаться в /var/log/ (например, мне :-) ), есть возможность посмотреть основные логи прямо в консоли управления DR.

Переходим на вкладку Configuration, заживаем Shift, кликаем на ссылке Log и "прокачиваем" консоль c Basic до Advanced ;-)

Аналогично можно получить доступ к выбору уровня отображения логирования.

По kb 1022680

Написать комментарий
⇤ Последнее
Первое ⇥
← Позже 1-я (и последняя) страница Раньше →