Всегда говори да!

«Обычно люди обращаются за советом, — говорил Атос, – только для того, чтобы не следовать ему, а если кто-нибудь и следует совету, то только для того, чтобы было кого упрекнуть впоследствии.»

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

  1. 2009-й год, я работаю обычным системным администратором на заводе. Windows, Exchange и немножко ДрВеба с Симантеком :).
    Тут мне предлагают стать ответственным за администрирование коммутаторов, маршрутизаторов и брандмауэров Cisco. В качестве бонуса еще и немного учат!
    Я, конечно же, соглашаюсь. Коллега из соседнего отдела сомневается и отказывается – зачем ему дополнительный головняк?
  2. 2011 год, в другом месте мне предлагают взяться за администрирование системы MS Lync Server 2010. Тоже учат, ага…
    Там же ближе к 2017 – внедрить систему резервного копирования NetBackup.

Результатом первой возможности стало более глубокое понимание работы сети и сертификат CCNA (хотя, поработав в интернет-провайдере, я осознал – насколько же это были базовые знания). Пару раз помогало тыкать носом сетевиков в их косяки.
Результатом второй и третьей – приличные знания по обеим системам в качестве T-shape специалиста. В результате, в 2020м меня брали на центрального администратора Commvault с хорошим окладом без практического опыта по нему 😉

Я не могу рассказать о текущем стеке, но он не имеет ничего общего с привычным мне VMware/Microsoft. Когда-нибудь я расскажу и эту историю…

Добавление FC-коммутаторов с FabricOS 9.x в Brocade Network Advisor

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки Broadcom. Любое использование оборудования вне списков совместимости Broadcom может быть использовано только на свой страх и риск. В статье рассматриваются коммутаторы на основе G620 первого и второго поколения. BNA ничего не знает про новую функциональность FabricOS 9.x и не сможет с ней правильно взаимодействовать.

Для управления FC-фабриками мы используем Brocade Network Advisor, который прекратил свой жизненный путь и заменен на SANNav.

К сожалению, SANNav поставляется по подписки и у нас есть проблемы с её приобретением.

Первой проблемой для нас стало то, что последняя версия BNA 14.4.5 перестала интегрироваться с VMware vCenter 7.0. Пришлось интеграцию удалить.

Второй проблемой – отсутствие поддержки Fabric OS 9.x, которая стала базовой для новых и обновленных коммутаторов.

У нас коммутаторы G620 второго поколения отображались в схеме фабрик как имеющие неправильные имя-пароль для подключения. Изменение настроек в разделе snmp коммутаторов и сервера – задание уровня шифрования для пользователя мониторинга в BNA и коммутаторе, включения информера не помогали.

Просмотр текущих настроек snmp:

Изучение настроек BNA выявило, что для сканирования оборудования фабрик используется аккаунт domain\access_bna, то есть коммутаторы должны позволять вход под доменными учётными записями.

Настроили и для новых коммутаторов RADIUS- авторизацию:

После этого коммутатор стал доступен для мониторинга и отобразился в схеме фабрики.

А вот коммутатор в другой фабрике по-прежнему остался недоступным. В консоли BNA выводилась ошибка с фразой:

Начали выяснять отличия первого коммутатора от второго.
Вспомнили, что на первом ломала и пересоздавали сертификат для подключения по https, а второй избежал этой участи, так как  проблема была в браузере – подключаться необходимо из Windows 10 с установленной кодовой страницей профиля пользователя EN-US.

Просмотр сертификатов для https выдается командой:

Разница видна сразу:

Команда генерации сертификата, по найденному лайфхаку, была:

Примечание: не все советы в интернете оказываются полезными. Помните это, читая и данную статью!

Создали новый сертификат с другим алгоритмом, соответствующий второму коммутатору:

После перегенерации сертификата, BNA увидел коммутатор и в этой фабрике.

Veeam Backup&Replication и восстановление дедуплицированных дисков

При попытке восстановить файлы на дедуплицированных томах из виртуальной машины с помощью Veeam BR FLR процесс восстановления зависает.
При запуске восстановления появляется сообщение:

Это связано с отсутствием компонентов дедупликатора. Добавляем их вручную на сервер Veeam BR:

Повторно восстанавливаем файлы.

Удаленное подключение к Linux через VMware Horizon Direct Connection

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки VMware. Любое использование программного обеспечения не соответствующего системным требованиям VMware может быть использовано только на свой страх и риск.

В разгар локдауна от ковида была написана статья о возможности использования прямого подключения к ПК по протоколу Blast (Blast Extreme) без использования серверной инфраструктуры VMware Horizon:

Удаленное подключение к ПК через VMware Horizon Direct Connection


В последние годы Linux приобретает всё большую популярность, как и потребность в удаленном подключении к нему.

В свою очередь, и компания VMware наращивает функциональность агента и клиента Horizon под операционные системы семейства Linux.

12 января 2023 года вышел релиз VMware Horizon 2212 (8.8). В этом релизе в агент для Linux добавили поддержку Debian 11.5, в котором мы и проведём наш эксперимент.

Для установки нам потребуется следующая документация:

и два дистрибутива агента и плагина:

  1. VMware-horizonagent-linux-x86_64-2212-8.8.0-21071111.tar.gz
  2. VMware-horizonagent-linux-vadc-x86_64-2212-8.8.0-21071111.tar.gz

В соответствии с системными требования проверяем версию Linux:

  • Ubuntu 18.04, 20.04, and 22.04
  • Debian 10.13 and 11.5
  • Red Hat Enterprise Linux (RHEL) Workstation 7.9, 8.4, 8.6, 8.7, 9.0, and 9.1
  • Red Hat Enterprise Linux (RHEL) Server 7.9, 8.4, 8.6, 8.7, 9.0, and 9.1
  • CentOS 7.9
  • SUSE Linux Enterprise Desktop (SLED) 15 SP3 and 15 SP4
  • SUSE Linux Enterprise Server (SLES) 15 SP3 and 15 SP4

и тип окружения рабочего стола: Continue reading “Удаленное подключение к Linux через VMware Horizon Direct Connection”