Veeam BR V11 поиск сессий с NBD

Для ускорения копирования данных VBR умеет использовать механизмы разгрузки сети: подключение дисков к проксирующим виртуальным машинам (ВМ) — hotadd, передачу по сети хранения данных — san, без разгрузки используется сетевой механизм nbd. При определенных изменениях (смена прокси, недоступность хранилищ по FC и прочие) в  инфраструктуре разгрузочные механизма могут отказать и будут заменены механизмом nbd. Пример поломки описан в базе знаний Veeam https://www.veeam.com/kb3204. Для диагностики проблемы в журнале задания VBR необходимо убедиться в наличие тэга [hotadd/san] либо появление тэга [nbd] при переключении механизма.

Поиск запроса для обнаружения заданий с NBD выдал скрипт, опубликованный на форуме Veeam — Find Sessions with specific transport mode.

Для запуска в версии V11 мы заменили импорт модуля  (How to Install Veeam PowerShell Snapin?):

Import-Module Veeam.Backup.PowerShell
$NBDSessions = $Null
foreach ($Job in (Get-VBRJob | where {$_.JobType -eq "Backup"}))
{
$LastSession  = $Job.FindLastSession()
$NBDSessions = $NBDSessions + (Get-VBRTaskSession -Session $LastSession | where {$_.Logger.GetLog().updatedrecords.title -like "*nbd*"})
}
$NBDSessions | select @{N="Job Name";E={$_.JobName}}, @{N="VM Name";E={$_.Name}}, @{N="NBD diks";E={($_.Logger.GetLog().updatedrecords.title | where {$_ -like "*nbd*"})}} | ft -AutoSize

Пример выдачи:

Job Name           VM Name          NBD diks                                                                                                                                                  
--------           -------          --------                                                                                                                                                  
Win2016_everyday   Win2016    Using backup proxy vbr-proxy-57 for disk Hard disk 1 [nbd]
Рубрика: 11, Backup&Replication, Veeam, Советы | Оставить комментарий

Статья про RAID

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

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

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

Итак, почему же всё-таки дешевые кунапы и прочие синолоджи – это «не СХД» или «недоСХД». Disclaimer (отмазка): мы искренне извиняемся перед всеми любителями утконосо… торговых марок QNAP и Synolodgy, а также всех их уважаемых представителей. Русские слова «кунап» и «синолоджи» применены автором как нарицательные, обозначающие продукты, несущие ниже описываемые недостатки.

Начнём с того, что полный хаос в чатах рунета порой творится даже с терминологией. Считается незазорным называть системы хранения данных начального уровня «NAS», противопоставляя их «взрослым двухголовым» системам, гордо именуемым «СХД». Не буду ввязываться в эти терминологические распри. Буду использовать термины «детская СХД», и «взрослая СХД».

Обязанность СХД – хранить данные. И отдавать их с гарантированной скоростью. И отдавать именно то, что было записано. Чтобы это делать используются всякие разные уровни RAID. Наиболее известный и распространённый – RAID5. Минус емкость одного диска из набора под четность – и вуаля: скорость линейного чтения почти равна скорости дисков, помноженных на N-1, где N – количество дисков в группе (ну или помноженных на N — если включено упреждающее чтение). И устойчивость к выходу из строя любого одного диска из группы. LUN отдаётся хоть по NFS, хоть по iSCSI. Может, даже кэш есть (в старших моделях). Казалось бы, что еще нужно?

Но емкости дисков (читай – плотность записи информации на пластину) растут. И если вдруг кто не знает, то уже давно то, что головка чтения-записи записала на пластину, вообще не равно тому, что она считывает. А целостность данных обеспечивается магией высших порядков, начиная от PRML и продолжая жутко избыточным кодированием перед этой самой записью, и в процессе чтения непонятно чего. Т.е. вопрос, считаем ли мы с носителя то, что записали, это вопрос вероятности. Так-то! И злобная царица наук просто констатирует, что если вероятность скрытой ошибки чтения с купленного на массовом рынке диска 10^-14 – то вероятность словить скрытую ошибку при восстановлении массива RAID5 из 4×2 Тб дисков — 38% (источник https://qastack.ru/superuser/516949/formula-to-calculate-probability-of-unrecoverable-read-error-during-raid-rebuild). Ну или 4,7% — если вдруг случилось чудо, и купившие «дешевую коробочку» разорились к ней на диски энтерпрайз уровня с вероятностью 10^-15 (для еще более полного просветления можно покурить это: http://true-system.blogspot.com/2013/04/mtbf-afr-uer-raid.html ).

Эта же вероятность ошибки применима к простому чтению всей записанной информации с массива RAID5 в «кунапах и прочих синолоджи». Почему? А потому, что они дешевые. А значит – слабые процессоры, и софт, спроектированный «дешевыми архитекторами» и написанный «дешевыми программистами». ) И поэтому, пока коробочка считает, что все диски из набора «в поряде» — она просто считывает страйпы и отдаёт их в сеть. Не проверяя четность. Ибо если бы проверяла – процессор, запроектированный «дешевыми архитекторами» или «ушлыми маркетологами», был бы нагружен на 146%, и коробочка не выдавала бы и половины от «заявленных мегабитов» даже в режиме потокового чтения.

И это очень легко проверить: берете коробочку по вкусу, пихаете три диска (минимум для RAID5), собираете массив и записываете первые пару гигабайт повторяющейся регулярной последовательностью, например, 1234567890. Затем выключаете коробочку, открываете, достаёте один диск, пихаете его в виндовую машину и открываете – да хоть WINHEX’ом. Видите вашу повторяющуюся последовательность, перемежающуюся белибердой через -цать секторов, равных в сумме двум размерам страйпа рэйда. Белиберда, понятное дело, это контрольная сумма N-1 страйпов. А теперь меняете в одном секторе один из блоков 1234567890 на, к примеру, 1334567890. Имитируя тем самым ту самую 10^-14 скрытую ошибку, когда бит поменялся и в секторе, и в его контрольной сумме на диске.  Вставляете в коробочку, включаете и считываете записанное по сети. Ставлю три своих шляпы, что в 8 случаях из 10 вы получите на дешевых коробочках в считанном файле 1334567890 (просто запустите поиск в считанном файле). Потому что, как и было сказано, даже если программисты, писавшие прошивку коробочки, «не дешевые» — дешевый процессор и требования маркетологов «выдавать на гора большие числа скорости чтения» не позволяют им посчитать контрольную сумму при каждом чтении. Контрольная сумма будет использоваться только при работе коробочки после сбоя диска, и при восстановлении (ребилде) массива после его замены. С дикими штрафами к производительности, либо сильно растянутым во времени ребилдом. За это отвечает настраиваемый вами параметр «приоритет ребилда» или «приоритет фоновых операций».

Ну а теперь самое весёлое:  фоновая проверка целостности. )) Самые догадливые уже смеются тут вместе со мной; остальным объясняю: фоновая проверка массива нашла несовпадение данных и контрольной суммы. А теперь вопрос – а где произошла скрытая ошибка? В страйпе данных или в страйпе контрольной суммы? Что исправить на диске? Или, если недешёвый программист таки-умудрился впихнуть в «узкие штанишки» дешевого процессора подсчет контрольной суммы при чтении: что отдать в сеть – вычисленный из контрольной суммы блок или считанный с дисков? ) И который из вычисленных – с первым диском, или со вторым? )) Что решил программист конкретной коробочки легко проверить, запустив фоновую проверку рэйда после внесения изменений, описанных выше. И прочитав результат. HINT – можно делать массив не на всю емкость, а на десяток гигабайт, тогда он перемелет раздел быстро. Но автор уверен, что никто из читателей проверять не будет, поэтому сразу спойлер, т.е. ответ: в 100% случаев в RAID5 исправят контрольную сумму. Ибо когда один из дисков – всё, то выхода в общем-то, нет. Чтобы отдать в сеть блок при сбое диска его вычисляют из тех, что остались. А когда все диски живые, то (осторожно, немного лайтового матана инклудед; A,B – страйпы данных, С – страйп с суммой A xor B):
Читаем страйпы, A xor B = C  — всё Ок, данные целостные. И тут вдруг
A xor B != C – блжад, проблема детектед. Но:
A xor C != B, твайу-ж мать, но и B xor C != А, сцуко! И куда бежать, кому сдавацца? Делать нечего, поэтому, плюют через плечо три раза и, помолясь, что ошибка всё-таки в страйпе с четностью, исправляют страйп С. И в 33,(3)% случаев оказываются правы. Фу-х-х, пронесло…

Для тех, кому 33,(3)% и «пронесло» не подходит, придумали сначала RAID51, а потом и 6.  Особо упоровшиеся (в хорошем смысле) по матану и вероятностям словить скрытую ошибку разработчики запилили RAID 7.3, и даже RAID N+M, где M – количество страйпов четности. Но 51 – это потеря половины емкости массива, а потому жалко и редко используется. А вот 6 или прости-господи, 7.3 – это уже любопытнее. Там _больше одного_ блока с четностью. И поэтому можно попытаться задетектить, который из страйпов «икнул», и исправить конкретно его. Но когда, при чтении? Да! Хорошо бы. Как своими руками проверить, делает ли это конкретная коробочка, вы теперь уже знаете. )) И уже почти самостоятельно можете осознанно принимать решение, что перед вами – «детская» СХД или «взрослая».

Исходя из вышеизложенного:
А) Всё, что умеет RAID5 и не более – просто по определению не может носить гордое название «взрослая СХД».
Б) Всё, что умеет больше, чем RAID5, но не проверяет суммы при каждом чтении каждого блока – не может носить гордое звание «взрослая СХД».

Едем дальше, или очень короткий абзац. Система хранения, как и друг, познаются в беде. А какая беда у системы хранения? Выход из строя железа, конечно. Причем погибнуть может не только диск. Может заглючить матплата, проц, и память кэша. Выход один – дублирование контроллеров. Вывод: система без дублирования контроллеров в продакшене – это рисковая авантюра, а не «взрослая СХД». А кроилово, как известно, всегда ведет к попадалову.

Теперь диски. Ох уж эти диски… Раньше, когда я был молодым и неопытным, я ненавидел маркетологов «взрослых СХД» за вендор-локед диски в этих самых взрослых СХД. Ну какого хрена, вопил я про себя и иногда на форумах, эти пип-пип маркетологи не позволяют пихать во «взрослые» системы купленные по-дешевке Б/У диски?! Потом, понапарывавшись на разваливающиеся, на казалось бы ровном месте массивы и проведя бессонные ночи за софтварным склеиванием развалившихся RAID5, 10, 50 – стал много читать. И однажды наткнулся на https://habr.com/ru/post/92701/ которая меня весьма просветлила. Коротко – что делает «обычный» диск (пихуемый среднестатистическим админом в коробочку типа кунап или синолоджи), когда напарывается на вполне себе нескрытую ошибку, т.е. контрольная сумма сектора не совпадает с вычисленной? Ну конечно же начинает практически бесконечно «тупить». Пытаться считывать проблемный сектор снова и снова. Особо умные – уводя голову «чуть левее», или «чуть правее» от «дороги», в надежде таки-прочитать несносный сектор. А что делает raid-edition диск? Правильно, пробует сделать это 1, 2, 3 секунды, и честно говорит ERR. Потому что «знает» – он в массиве. Ну не читается сектор, «случилось дерьмо», что поделать? О, так ведь можно же вычислить целостный блок данных из страйпов четности! Что делает серьезная, взрослая СХД, увидев ERR при чтении сектора/блока? Ну, после того как вычислила и отдала блок в сеть?  Думаете, тут же зажигает диск красненьким? А вот и не всегда! ) Она-то «знает», что, возможно, просто при записи этого конкретного сектора что-то «моргнуло», и сектор «коряво» записался. И можно тут же (или чуть позже, когда нагрузка спадёт) попытаться перезаписать битый сектор правильной, вычисленной информацией. И он с высокой долей вероятности корректно запишется! И будет корректно писаться/читаться еще несколько лет (а если нет – то красненьким диск зажечь в этой ситуации еще не поздно), ибо remap секторов на HDD никто не отменял. Особенно если это и не HDD вовсе, а SSD, и контроллер носителя уже сделал ремап на резервный блок. Но «ложечки нашлись, а осадочек остался», поэтому «правильная», «взрослая СХД» уже поставила «маленький черный минусик» в свою «записную книжечку» напротив серийного номера носителя. И если таких «минусиков» вдруг начинает копиться на одном из носителей больше заданного уровня – вот тогда СХД зажжёт сначала жёлтую («не хреново было бы заменить…»), а потом и красную («меняй немедленно!») лампочку напротив слота с носителем. А если админ правильный, и позаботился о hot-spare носителях – то автоматически начнёт перестроение на них.  И это – только малая толика всего, что может должно происходить между хранилкой и носителями. К примеру, еще она может должна считывать SMART-атрибуты носителей, причем не один-два общих, а еще и кучку специализированных. И т.д. и т.п. Отсюда простой вывод: для обеспечения полноценного, грамотного хранения данных «взрослая СХД» просто обязана уметь общаться с носителями «на одном языке». И пока этот «язык» не выработан и не стандартизован (даже единого стандарта на SMART-атрибуты нет, чего уж говорить об остальном) – вендор-локед диски, разговаривающие с хранилкой на одном языке – единственный способ обеспечить ту надежность, что на полном серьёзе пишут в спецификациях «взрослых СХД». А иногда это пять девяток, а это уже совсем не хухры-мухры.

Ну а что делать, если и «взрослую СХД» хочется, и платить мегаденьги за вендор-локед носители жаба и/или бюджет не позволяют? Допустим, нашли мы недорогие диски, в которых SCT ERC можно поменять, и он даже не слетает в дефолт после отключения питания. Куда это всё запихать, чтобы и RAID 7.3, и «двухголовость», и контроль целостности и при чтении и фоновый, и чтобы медленные, «чуть-чуть» заикающиеся при чтении диски помечало сначала желтым, и только совсем мёртвенькие – красным, и на degraded массивах почти не тупило, и кое-что ещё? Хорошая новость – есть такая СХД! ) Плохая – если я её назову, то посыпятся обвинения в ангажированности, рекламе и прочем. Поэтому отделаюсь полунамёком: придумать такое могли только в одной стране. ))

Ну а что делает ваш любимый кунап с напиханными в него не raid-edition (которые, как я надеюсь к этому моменту понятно, SCT ERC disabled или =0) дисками всё это время? Да тупит он. Ибо не может решить, зажигать диск красным, или еще нет. А вслед за ним тупит, например, восстановление из бекапа, файлы которого админ положил на пресловутую недорогую коробочку. Или все виртуальные машины, попытавшиеся что-то считать или записать на «СХД». И даже если открытых ошибок на диске нет: что из-за скрытых ошибок не восстановится из бекапа емкостью в 15 Тб, записанном на RAID5 массиве из 10×2 Тб дисков – вопрос везения. Так царица наук сказала.  Ну а если админ «в порыве слабоумия и отваги» в него еще и SMR дисков напихал, то начинается совсем уж треш и угар, типа такого: https://habr.com/ru/post/497900/

Надеюсь, после этих размышлений вслух хоть немного поутихнут споры про то, что считать «недоСХД», а что СХД «взрослыми».

Считывающихся вам без ошибок бекапов, господа/товарищи!

Рубрика: Статьи | 1 комментарий

Релиз RVTools 4.1.2

Rob de Veij выпустил обновление своей отличной утилиты инвентаризации VMware vSphere — RVTools версии 4.1.2.

В этой версии появились новые функции:

  • RVTools msi теперь подписан сертификатом Sectigo
  • Log4net обновлен до версии 2.0.12 (как исправление для CVE-2018-1285)
  • Новая вкладка vUSB: отображаются виртуальные машины с подключенными к хосту USB-устройствами
  • Вкладка vFloppy удалена
  • Дополнительный флажок для «Wait for Get Friendly vSAN Names thread at startup». По умолчанию этот параметр отключен. Если этот параметр включен, RVTools сначала соберет понятные имена папок vSAN. Понятные имена vSAN отображаются вместо guid на вкладках vInfo, vDisk и vSnapshot
  • Новый ключ/параметр в CLI: -GetFriendlyNames для сбора понятных имен папок vSAN
  • Экспериментальная вкладка vFileInfo с подробной информацией обо всех файлах, найденных во всех хранилищах данных
  • Дополнительный флажок для «Get fileinfo detail information». По умолчанию этот параметр отключен. Если этот параметр включен, то RVTools будет собирать все сведения обо всех файлах во всех хранилищах данных.
    Предупреждение: это очень трудоемко!
  • Новый ключ/параметр в CLI: -GetFileInfo для заполнения вкладки vFileInfo.
  • На экране входа в систему номер сборки теперь также является частью отображаемого номера версии
  • Все соответствующие страницы вкладок VM теперь имеют новый столбец, указывающий, является ли она SRM placeholder’ом или нет
  • В форме фильтра теперь можно фильтровать SRM placeholder’ы
  • На вкладке vInfo теперь отображается до восьми сетевых карт (было четыре)
  • На вкладке vNetwork новый столбец: порядковый номер NIC
  • На вкладке vNetwork: столбец IP разделен на столбцы ipv4 и ipv6
  • На вкладке vDisk новые столбцы: ключ диска и путь к диску = имя виртуального диска в гостевой операционной системе. Например: C:\(работает только для vSphere >= 7.0)
  • На вкладке vDisk новый столбец: «Internal Sort Column» используется для сортировки данных vDisk по имени виртуальной машины и ключу диска
  • На вкладке vPartition новый столбец: «Internal Sort Column» используется для сортировки данных vPartition по имени виртуальной машины и ключу диска
  • На вкладке vPartition новый столбец: Дисковый ключ может быть использован для сопоставления диска vDisk с дисковым разделом
  • На вкладке vNetwork новый столбец: «Internal Sort Column» используется для сортировки данных vNetwork по имени виртуальной машины и имени сетевой карты
  • На вкладке vHealth имена папок vSAN теперь отображаются вместе с их понятными именами папок вместо guid
  • На вкладке vRP новый столбец: путь к пулу ресурсов
    На вкладке vRPtab новый столбец: общее количество виртуальных машин в resourcepool
  • На вкладке vHost новый столбец: общее количество виртуальных машин на хосте
  • На вкладке vHost новый столбец: vSAN Fault Domain Name
  • На вкладке vDatastoretab новый столбец: общее количество виртуальных машин в хранилище данных
  • На вкладке vHealth: новое сообщение безопасности, если на хосте запущена служба «ESXi Shell» или «SSH»
  • Все метки столбцов, содержащие MB, были скорректированы на MiB, потому что появилась путаница с новой системой размеров.
  • RVTools отобразит предупреждающее сообщение, если собрана не вся инвентаризация виртуальной машины. Похоже, что существует проблема десериализации XML, когда существует виртуальная машина с сотнями дисков. Проблема, по-видимому, в основном вызвана решениями для резервного копирования, которые не могут очистить все должным образом после завершения резервного копирования. В документации есть инструкция, как найти «плохую» виртуальную машину.
  • Исправлена ошибка: На вкладке vHealth изменена проверка «Inconsistent Foldername». Для vSAN понятное имя папки теперь сравнивается с именем виртуальной машины.
  • Исправлена ошибка: *-файлы digest.vmdk исключены для проверки зомби-файлов
  • Исправлена ошибка: общий размер файлов моментальных снимков
Рубрика: VMware, vSphere, Новости | Оставить комментарий

Утилита самообслуживания VMware Skyline Health Diagnostic Tool

Осенью 2020 года компания VMware анонсировала утилиту сбора и разбора журналов событий с vSphere 6.5, 6.7, 7.0 — VMware Skyline Health Diagnostic Tool.

  1. Introducing VMware Skyline Health Diagnostic Tool
  2. Перевод на русский Новая утилита VMware Skyline Health Diagnostic Tool — для чего она?
  3. VMware Skyline Health Diagnostics for vSphere Documentation
  4. VMware Skyline Health Diagnostics Installation, Configuration and Operations Guide
  5. Скачать

Утилита довольно просто устанавливается в виде ВМ, после этого указывается vCenter/ESXi, выбираются объекты для сбора логов и, подождав несколько десятков минут или несколько часов, получаем отчёты с замечаниями и ссылками на БЗ VMware.

Примечание. Утилита имеет довольно убогий интерфейс — если вы вышли из админки, то не видно есть ли текущие задания. Читать далее

Рубрика: 6.5, 6.7, 7.0, VMware, vSphere, Обзоры | 5 комментариев

Прекращение поддержки процессоров в VMware vSphere 7.Next

Как в случае и с предыдущими релизами, компания VMware решила заранее предупредить заказчиков о прекращении поддержки процессоров в следующей платформе виртуализации VMware vSphere 7.Next.

9 марта 2021 года вышла заметка в БЗ — Updated Plan for CPU Support Discontinuation In Future Major vSphere Releases (82794), содержащая большой список процессоров Intel и AMD, при установке vSphere 7.0 update 2 на которые будет возникать предупреждение:

CPU_SUPPORT_WARNING: The CPUs in this host may not be supported in future ESXi releases. Please plan accordingly.

Больше всего озадачило прекращение поддержки серий процессоров Intel Xeon E5-2600-v1/v2 и даже v3. Если первые два поколения уже довольно пожилые, то третье поколение встречается в 4-5-летних серверах. Пользователям остаётся только вариант замены Xeon E5-2600 v3 (Haswell) на v4 (Broadwell), но даже б/у оборудование стоит очень прилично — от 500 долларов за средний в линейке процессор.

Напоследок картинка с доработками аппаратной виртуализации в Broadwell и улучшениями задержек при операциях VM Enter/Exit между поколениями Xeon на базе архитектуры Core :

Рубрика: 7.0, VMware, vSphere, Новости | Оставить комментарий

Продукты VMware — весна 2021

Этим мартом компания VMware выпустила огромное обновление своих продуктов:

Выпущено много новых заметок в базе знаний по проблемам, планам, принятым решениям по платформе VMware vSphere 7.0 Update 2:

Рубрика: 7.0, Horizon, VMware, vSAN, vSphere, Новости | Оставить комментарий

Transport (VMDB) error -45: Failed to connect to peer process после обновления VMware ESXi

mr_orangeV прислал заметку о решение проблемы с VMDB transport.

После обновления ESXi до версии 6.7 сборка 17499825 и вывода хоста из режима обслуживания, виртуальные машины не мигрировали обратно на хост с ошибкой:

Transport (VMDB) error -45: Failed to connect to peer process

Поиск корневых причин привёл к нескольким вариантам:

  1. Опять кто-то где-то напутал в коде, такое уже было у HPE, можно поискать по фразе » had a bug that constantly wrote logs to the /tmp/vmware-root folder that eventually filled up the partition».
  2. Кончилось место, в том числе под swap.
  3. Mac OS Unlocker или в работе, или криво удален.

Как найти реальную причину?

Для начала прочитать все, что написано в комьюнити и БЗ: ссылка 01 и ссылка 02 kb 50113127.

Во второй KB указано, что  «Confirm the presence of the Unlocker installation on the ESXi host using one or more of the following commands».

В моём случае эти команды не показали ничего, а команды ls -l /bin/vmx в kb нет.

Подключаемся к хосту по SSH и GUI, смотрим:

  • Проверяем место: df –h
  • Проверяем Ramdisk: vdf –h
  • Проверяем snmp по kb 2040707 и inode: stat -f /vmfs/volumes
  • Проверяем что у нас с симлинками: ls -l /bin/vmx
  • Читаем (можно из GUI хоста) vmkernel и vpxd логи
    Ищем строки вида «vmx: Error in initial cartel setup: Failed to open /bin/vmx: Operation not permitted»

В моем случае, это оказался неудаленный полностью Unlocker.

Шаги решения

  • cd /bin
  • ls -l /bin/vmx и посмотреть куда он ведет
  • cd /куда ведет симлинк и
  • ls посмотреть на наличие vmx и unlocker
  • cd /bin
  • rm vmx – удалилить симлинк
  • cp /откуда)/vmx  /bin

Материалы для внеклассного чтения Читать далее

Рубрика: 6.7, VMware, vSphere, Советы | Оставить комментарий

Релиз Veeam Availability Suite V11

Veeam выпустила новую линейку своих продуктов:

Рубрика: 11, Backup&Replication, Veeam | Оставить комментарий

Обновление VMware vCenter путем его замены

mr_orangeV прислал статью о своём опыте замены VMware vCenter.  С небольшой редактурой публикую. Юмор автора местами сохранён.

В последнее время читаю много однотипных историй «у нас ESXi 5.1/5.5 /6 — как нам жить дальше или  на что-то переехать?» Расскажу свою историю, может кому-то поможет.
Нам достался подряд на обследование и модернизацию инфрастуктуры одной организации. Беглый осмотр показал следующее:

  • десяток разных серверов (с разными процессорами) на ESXi 6.0/6.5/6.7;
  • некая СХД, работающая по протоколам NFS/iSCSI;
  • невнятная сеть почти без деления (лучше бы было совсем без деления, так как я такого ужаса еще не видел).
  • VMware vCenter 6.5 на Windows, обновленный последний раз очень давно;
  • полное отсутствие документации «что, где, куда и почему»;
  • под сотню виртуальных машин, которые, конечно же, все очень важные и нужные. И тоже без обновлений! Настоящие админы до второго сервис пака не обновляют, но с Windows Server 2016/2019 есть проблема при таком подходе.
  • cостояние резервного копирования неочевидно.

Для ликвидация хаоса были предприняты следующие шаги: Читать далее

Рубрика: 6.0, 6.5, 6.7, VMware, vSphere | Оставить комментарий

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 в качестве атрибута

get-aduser -filter * -SearchBase ou=ou1,ou=ou2,dc=domain,dc=ru" -Properties cn,canonicalname | select name,userprincipalname,@{Name="OU";expression={$_.Canonicalname.substring(0,$_.canonicalname.length-$_.cn.length)}}
Рубрика: Советы | Метки: | Оставить комментарий