Синхронизация ВМ с хостов

Мы ранее уже писали про тонкости синхронизации времени с хостом.

А сейчас речь пойдет про локальное время на хосте и опцию по синхронизации времени ВМ с хостом, появившуюся в vSphere 7.0.

Для того, чтобы узнать локальное время на сервере ESXi в часовом поясе UTC+0, можно воспользоваться следующим скриптом PowerCLI:

Если захотите побольше узнать про вложенные свойства ConfigManager.DateTimeSystem, то можно воспользоваться фильтром к Get-View и параметром -ExpandProperty (ниже будет приведен пример для виртуальной машины).

Для того, чтобы узнать, синхронизирует ли свое время виртуальная машина через VMware Tools с хостом, можно воспользоваться одним из вариантов ниже.

Для vSphere 7.0U1 и выше:

Для более старых версий:

Отличие 7.0U1 от более старых версий в том, что свойство SyncTimeWithHost переключает разные настройки ВМ. В новой версии появился дополнительный флаг — «Synchronize time periodically», который отвечает за синхронизацию времени с хостом раз в 60 секунд (по умолчанию отключен).

Соответственно, свойство «SyncTimeWithHost» в 7.0.1 переключает не общую синхронизацию времени, а именно «периодическую» синхронизацию. В более старых версиях это свойство отвечает за общую синхронизацию времени, тогда как в 7.0.1 за общую синхронизацию стал отвечать параметр SyncTimeWithHostAllowed!

P.S. Для того, чтобы узнать больше о содержимом вложенного свойства, например, Config.Tools, можно воспользоваться следующим фильтром:

VeeamONTour 2021

Всем привет!

Приглашаем Вас 16 июня 2021 года на онлайн-конференцию #VeeamONTour «Эффективная стратегия защиты данных» по этой ссылке.

Я и другие блогеры записали для вас видео-приглашение:

Как я доменный контроллер переносил

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

  1. проверить текущих владельцев FSMO-ролей,  при необходимости — передать их на другой сервер, остающийся в работе;
  2. проверить настройки DNS, чтобы оба сервера использовали в первую очередь рабочий DNS;
  3. проверить статусы репликации NTDS (AD) и SYSVOL;
  4. убедившись, что все работает, понизить контроллер домена, сменить имя и адрес;
  5. назначить имя и адрес новому готовому серверу;
  6. поднять на нем роль контроллера домена.

Как видите, ничего сложного, поэтому я оценил общую трудоемкость задачи в 4 часа, как обычно заложив запас под 100% на работы.

Кстати, в статье заложена пасхалочка-бонус 🙂

Давайте вместе посмотрим, что же из этого вышло…

Читать далее «Как я доменный контроллер переносил»

Статья про RAID

@kr0k0k0t прислал статью про неСХД и RAID.

Вместо эпиграфа:
«Был неправ, вспылил. Но теперь считаю своё предложение безобразной ошибкой, раскаиваюсь, прошу дать возможность загладить, искупить. Всё, ушел.» (C) «Обыкновенное чудо.»

Часто приходится быть свидетелем споров типа «а QNAP – это СХД?» «В чем разница между СХД и NAS?», «а можно ли использовать QNAP такие-то цифры для бекапов?» и т.п. Вот и здесь недавно было. Посему, в качестве деятельного раскаяния за флуд решил поделиться своим IMHO’м на эту тему. Возможно, будет для кого-то полезно. Осторожно, многабукаф. Читать далее «Статья про RAID»

Get-ADUser и Organization Unit

Возник вопрос: как экспортировать список пользователей из AD с организационным подразделением (Organization Unit или OU).

Get-ADUser user -Properties * показал, что OU присутствует в двух атрибутах:

  • Distinguishedname: CN=user,ou=ou1,ou=ou2,dc=domain,dc=ru;
  • CanonicalName: domain.ru/ou2/ou1/user

В готовом виде OU нет, хотя для целей сортировки удобнее использовать CanonicalName.

Так родился «однострочник», позволяющий вытащить OU в качестве атрибута

vExpert 2021

На прошлой неделе коллектив авторов блога заработал очередное ежегодное звание —  vExpert 2021.

Найти нас в списке легко — надо написать vMind 🙂

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

Каждая звезда обозначает год владения статусом vExpert у нашего блога.

Еще несколько лет, и бложек станет совсем взрослым…

Zerologon check (проверка)

Как вы слышали,  в августе 2020 года была обнаружена критическая уязвимость CVE-2020-1472 в протоколе проверки пользователя контроллером домена.

Критическая она потому, что для эксплуатации этой уязвимости достаточно оказаться в одной сети с контроллером домена.

Microsoft конечно же выпустил обновления, но кто ж их ставит, верно?

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

Поэтому я написал скрипт, который проверяет наличие требуемых обновлений на контроллерах домена Windows Server 2012 R2.

Список обновлений взят из статьи про уязвимость, а также Catalog MS, указывающего на более новые версии обновлений. В моем списке сентябрьское обновление, два августовских и перекрывающий их апдейт безопасности для Windows 2012 R2.

Обратите внимание, что для Windows 2016/2019 номера апдейтов другие!

Для запуска скрипта требуются права администратора домена, так как скрипт проходит по контроллерам и через WMI получает список установленных обновлений.

Результатом работы скрипта является следующий вывод:

WARNING означает, что нужно срочно бежать и ставить обновления.

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

VCP:DCV2020 от Veeam

Наш спонсор, Veeam, выпустил обновленную версию неофициального гайда по подготовке к экзамену VMware Certified Professional on DataCenter Virtualization (VCP:DCV2020).

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

Руководство подготовлено Shane Williford и Paul Wilk, имеющими общую цифру 2x:

  • Шейн в ИТ более 20 лет;
  • Пол пока не разменял третий десяток 😉

P.S. А еще Пол похож на того мужика, что сует 1С в Кубернетис.

Много проблем с VMware Data Recovery

Много лет назад VMware решили, что неплохо было бы сделать свой бэкап-софт для виртуальной среды. Так и появился VMware Data Recovery.

Софт был несколько глючный, поэтому через несколько версий/лет (и объединение с EMC) VMware похоронило свою разработку и сделало vDP на базе EMC Avamar.

На этом глюки поуменьшились, но VMware и этого было мало, вследствие чего поддержка vDP была окончательно похоронена (в 2019 или 2020 году)…

  1. Как-то сдох у меня основной сторадж, на котором лежало все: виртуалки, контроллер домена, vcenter 6.0. Остался жить только vdp и еще один виндовый сервер, лежащие на локальных дисках ESXi. Стоит отметить, что места на локальных дисках ESXi под все виртуальные сервера из бэкапа не было. Но это не стало основной проблемой 😉
  2. Я зашел на веб-интерфейс vDP и запустил Emergency Restore трех продуктивных виртуальных машин (топ по критичности). Это была главная ошибка: надо было сначала восстанавливать DC/VC.
  3. Три критичных виртуалки восстановились, после чего веб-интерфейс vDP отмер — по таймауту. В течение суток и пары ребутов vDP восстановить его не удалось, пошли в саппорт.
  4. Ахмед сказал, что vDP окончательно слетел с саппорта и добавил: «я не гинеколог, но посмотреть могу». Посмотрел на мое горе, посоветовал развернуть максимально свежую версию vDP и вставить диски туда/либо развернуть vDP 6.1.2 и подоткнуть диски туда.
  5. В штатном режиме vDP развертывается (ovf deploy) только через vCenter. 😉 (Ох щит) (это знак, что стоило сесть за чтение документации по развертыванию vDP)
  6. Я отредактировал вручную .OVF и успешно импортировал виртуальную машину;
  7. Затем я научился менять ip-настройки SLES11 из командной строки;
  8. После этого запустился инсталлятор vDP из веб-интерфейса и… напоролся на проблемы с отсутствием записей DNS.
  9. Ну вы помните, что у меня рабочих систем нет и я работаю в выжженом поле 😉 Ладно, побороли и DNS.
  10. На следующем шаге vDP сказал, что ему нужна для развертывания регистрация в vCenter. АААааааа 😊
  11. В силу ограниченных ресурсов я попытался развернуть vCSA 6.0. Ожидаемо встал на грабли плагина интеграции с браузером, который не захотел устанавливаться.
  12. Мыши плакали, кололись, но продолжали есть кактус.
  13. Я решил рискнуть костями и поставить vCSA 6.5. Да, по матрице он не совместим с vDP 6.1.2, но мало ли что. Впрочем, vCenter развернулся штатно (хоть что-то).
  14. Ожидаемо, регистрация vDP 6.1.2 на vCSA 6.5 не проходит. (непереводимая игра слов)
  15. Развернул через vCenter vDP 6.1.11 — он нормально прошел регистрацию на vCSA 6.5. С замиранием духа втыкаю в него VMDK от старого vDP и прожимаю импорт. Через полчаса…
  16. Через полчаса vDP 6.1.11 говорит, что пароль рута к дискам не подходит. Кстати говоря, эта же проблема имела место год назад. Тогда vDP 6.1.2 не стартовал, импорт дисков не помогал. Тогда vDP мне починил инженер из саппорта (фактически, специалист по Авамару и линуксу, судя по тому трешу, что он творил в консоли)
  17. Остается обратно лохматить старый и неподдерживаемый vDP.
  18. Обратно включаем с дисками старый vDP 6.1.2.
  19. Веб-интерфейс старого vDP открывается, но говорит «ждите до 25 минут, запускаемся»;
  20. В консоли старого vDP вижу, что не запускается служба MCS из-за проблем с чекпоинтами. К счастью есть статья в КБ (https://kb.vmware.com/s/article/2053986), служба запускается и…
  21. Еще минут через 5-10 запускается веб-интерфейс. И я могу продолжать emergency restore!!!11111

Выводы:

  1. Никогда. Не. Используйте. VMware Data Recovery!
  2. В DR-план восстановления инфраструктуры заложите восстановление самого сервера резервного копирования в случае какого-либо сбоя. Ну и тестируйте это (DR — Disaster Recovery, восстановление после катастрофы)!
  3. Я крайне не рекомендую использование в продуктиве софта, для DR-переустановки которого требуется куча «левых» компонент типа vCenter.

P.S. Впрочем, это одна из причин, по которой VMware «мигрировали» vDP на Avamar. До Avamar vDP метаданные держал в базе vCenter. Нет vCenter — ну вы поняли 😉

VeeamOn Tour 2020

Всем доброго времени суток.

25 июня с 11:00 до 13:40 компания Veeam приглашает всех на конференцию VeeamOn Tour 2020. Из-за того, чье имя нельзя называть, встреча будет проходить в онлайн-режиме.

На выбор доступны 6 технических сессий:

  1. реализация Veeam NAS Backup в версии 10;
  2. практические рекомендации по защите данных от программ вымогателей;
  3. рекомендации по планированию инфраструктуры Veeam Backup & Replication v10;
  4. лучшие практики и рекомендации для успешной работы с Veeam Agents;
  5. все об интеграции с СХД и новые возможности Veeam v10;
  6. защита данных облачного Microsoft Office 365.

Будут сессии по облачной стратегии защиты данных.

Участие бесплатное, требуется регистрация.

P.S. Если желаете вспомнить, как это было в офлайн-эпоху, есть фотоотчет о посещении VeeamOn Tour 2016.

P.P.S. По данному тэгу вы можете просмотреть ссылки на конференции, проходившие в прошлых годах.