Одинаковые МАС адреса для всех сетевых адаптеров блейд серверов, работающих в режиме NPAR.

Добрый день, коллеги.

Столнулись с фитчей/багом Lenovo, приводящем к установки одинаковых МАС адресов для всех сетевых адаптеров блейд серверов, работающих в режиме NPAR.

Мы использовали шасси 8721ALG и блейд серверы Lenovo Flex System x240 M5.

Сетевые адаптеры блейдов Qlogic 577xx/578xx 10 Gb Ethernet BCM57840, Broadcom NetXtreme II 2-Port 10GBEthernet Adapter BCM57840 – в разных блейдах могут быть разные адаптеры, соотношение типов 90% к 10% в пользу QLogic.

Все блейд серверы в шасси были настроены в режиме NPAR и работали штатно, была установлена ОС Linux, собраны bonding  и т. д.

 После того, как шасси было раскомплектованно для транспортировки и собрано вновь (изъяты блейдыи вставлены обратно), ВСЕ БЛЕЙДЫ  (тождественно для всех  используемых корзин) получили «фейковые» МАС адреса, а не реальные (как видно из скриншота ниже; формат адреса 00:0A:F7:56:85:Cx, где Х порядковый номер сетевой карты в ОС), что привело к неработоспособности сети, а так же ранее установленной ОС Linux. При этом, отчёт шасси показывал реальные МАС адреса.

Провозившись некоторое время нашли workarround для этой проблемы:

•  перевод сетевых адаптеров блейд в режим UFP;
•  сохранение настроек и рестарт блейда;
•  перевод адаптеров блейд в режим NPAR;
•  сохранение настроек и рестарт блейда;

с переводом в режим PNIC не сработает, сброс на блейдов на фабричные настройки эффекта не даёт.

Путаница с сетевыми адаптерами RELS 6.7 при использовании Switch Independent (NPAR) режим на Lenovo Flex 240 M5

Доброго дня.
Столкнулся с интересным багом или фитчей.

В проекте использовали блейды Lenovo Flex 240 M5  с сетевыми адаптерами (Qlogic 577xx/578xx 10 Gb Ethernet BCM57840 и Broadcom NetXtreme II 2-Port 10GB Ethernet Adapter BCM57840).

По производственной необходимости было принято решение о использовании Switch Independent виртуализации физических сетевых адаптеров (NPAR режим). Операционная система RELS 6.7 с ovirt агентом на борту (NetworkManager вначале был запущен).

В какой-то момент, на одном из блейдов я выключил виртуализацию сетевых адаптеров и настроил бондинг прямо на физике. Однако, трафик не шел... т.е. всё: от сети, заканчивая блейдом и бондом в режиме 5, работало штатно, но трафик не шел...network перезапускался штатно.

По совету вендора проверил файл /etc/udef/rules.d/70-persistentnetrules и выяснил, что по какой-то причине имена сетевых адаптеров были перепутаны!  Естественно имя адаптера не соответствовало его МАС адресу, что и вызывало проблемы.

После корректировки имён адаптеров - всё заработало.

Быстрое развёртывание контейнеров из шаблона с IIS 10 на борту

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

 

Для начала создадим новый контейнер.

Далее, мы установим в него поддерживаемое приложение - для нас это будет Internet Information Server 10. Да, для того, чтобы воспользоваться преимуществами контейнеризации Ваши приложения должны "уметь" работать в минималистичной среде контейнера. Пока что, мы можем использовать список поддерживаемого ПО



 

 

Мы видим, что установка прошла штатно

 

Мы можем посмотреть список установленного функционала IIS сервер. 

 

Далее, мы останавливаем наш контейнер и

 

И выполняем процедуру создания шаблона

 

 

ПРИМЕЧАНИЕ! На всех узлах контейнеризации у нас присутствует модуль Powershell Containers. Этот модуль и позволит нам выполнить элементы автоматизации в сценарии ниже.

 

 

DEMO - PoC

 

Итак, приступим...

Предположим, что мы работаем в неком облачном сервис-провайдере и клиент у нас заказывает некое кол-во IIS серверов (допустим через WAP со связкой SFP  и. т.д.).

 

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

 

 

Задаю переменную, которая содержит наименование шаблона

 

 

И запускаю скрипт .\AutomationDemo.ps1

 

Скрипт запросит кол-во копий веб-сервера, которое мы хотим получить, и наштампует запрошенное из шаблона

 

Наши сервера запущены и работают.

 

Для проверки мы подключаемся в один из них.

 

 Получаем PID CSRSS процесса и смотрим какой функционал у нас присутствует в контейнере-клоне. Вот наш IIS сервер.

 

 

Ну и собственно процессы контейнеров, созданные из шаблона на сервере контейнеризации...

 



 

 

 

Пляски с контейнерами Windows Server 2016 CTP3 (как установить)

Добрый день.
 
Разбирая новый функционал Windows Server 2016 CTP3 невозможно не коснуться темы с контейнерами. Собственно, у меня в лаборатории есть 2-х узловой кластер, который я использую для всяческих экспериментов.
 
Для ознакомления с темой контейнеризации я бы использовал несколько статей, расположенных по ссылке Windows Containers, для быстрого понимания темы можно внимательно прочитать FAQs. Известные проблемы и ограничения для контейнеров в Windows Server 2016 CTP опубликованы тут.
 
Для развёртывания демо-среды контейнеров используются два подхода:

• Развёртывание "с нуля", включая виртуальную машину;
• На существующей виртуальной машине;

 
При развёртывании "с нуля" используется скрипт New-ContainerHost.ps1 - он позволяет скачать необходимые части для развёртывания из Интернет, подготовить виртуальную машину и т.д.
 
При установке с помощью скриптов виртуальная машина сервера и её диски размещаются по путям, указанным в Hyper-V по-умолчанию. Если вы хотите, чтобы виртуальная машина попадала на CSV - сделайте настройку в оснастке Hyper-V Manager . Гипотетически можно попытаться изменить строку номер 110 в скрипте - напрямую указав путь к требуемой папке на файловой системе.
 

 
Собственно, на скриншоте ниже можно ознакомиться с процессом развёртывания. В данном случае я ещё не модифицировал пути размещения компонентов виртуальных машин.
 
ПРИМЕЧАНИЕ! После установки вы можете выполнить команду Move средствами оснастки Hyper-V Manager и положить файлы виртуальной машины на нужное хранилище.
 
Последней командой я присоединил виртуальную машину к виртуальному коммутатору.
 



 

Однако, как видно из скриншота выше, по-умолчанию создаётся виртуальный свитч контейнер в режиме NAT и возможности выбора никто не предложил. Мне это не понравилось, да и излишне усложнило тестовый стенд. Посему я занялся поиском возможностей обхода этого технологического решения.

 

Как выяснилось, после создания гостевой виртуальной машины, в корне системного диска можно обнаружить файл Install-ContainerHost.ps1.  Там же лежали файлы логов, и ответов.

 

 

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

 

 

 

Модифицированный скрипт со второй попытки при развёртывании "с нуля" можно положить следующим образом:

 

 
Как видите, я и путь поправил.
 

 

Данный файл скрипта идентичен файлу, который используется при установке на существующую виртуальную машину ContainerSetup.ps1. Для второй попытки я подготовил другую виртуальную машину и скачал этот скрипт с помощью команды:

 

wget -uri https://aka.ms/setupcontainers -OutFile C:\ContainerSetup.ps1

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

 

 

 

 

 

 В процессе работы скрипта, появились дополнительные файлы

 

Файл Install-ContainerHost-Bootstrap.ps1 содержит закладку на перезапуск скрипта, после перезагрузки системы.

 





 

Казалось установка шла штатно, но как и в первом эксперименте с изменённой версией скрипта Install-ContainerHost.ps1 у меня возникла проблема

 

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

Однако, после добавления второго интерфейса - IPv4 адрес с настройками был успешно получен.

С другой стороны, проблема возникала на этапе "Creating container switch (DHCP)".... Но, у меня на интерфейсе задана статика... Вероятно на одном и том же интерфейсе не могут фигурировать два MAC без включенного MAC Address Spoofing, что не даёт возможности работать с DHCP.

После этого, я решил включить Mac Address Spoofing, и ещё раз внимательно прочитать раздел Work in Progress - к моему удивлению моя теория подтвердилась см.раздел Networking по ссылке. Это побочный эффект, возникающий при использовании одного ядра и ОС, и контейнерами, без включенного Mac Address Spoofing - всё контейнеры получают один и тот же MAC.

После удаления vSwitсh, чтобы избежать проблем при перезапуске скрипта, процесс пошел.

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

 

Обе мои системы успешно были развёрнуты :) можно приступать к тестированию.

Создаём наш первый контейнер из Default image

 

Изменение версии ядра узла виртуализации ROSA Linux "на лету"

Всем привет.

Сегодня, по производственной необходимости (тестируем совместимость с Secret Net LSP), выполнил downgrade ядра на живом узле виртуализации RELS 6.6, даже с включенными виртуальными машинами.

ПРИМЕЧАНИЕ! Необходимо выполнить перезагрузку после изменения ядра.

Пока потерь нет.
 

Дело в том, что Secret Net LSP поддерживает ядро 2.6.32-431.el6.x86_64, соответственно продукт не взлетит на RELS 6.6, 6.7 из коробки.

По обновлению  поддерживаемых ОС для Secret Net будем делать запрос к вендору.

Типовые события журнала Operations manager by-Design

Event ID 1207 на обектах CNO и VCO

Для объектов CNO, VCO отлавливалось Event ID 1207. Возникает на узлах любого отказоустойчивого кластера, состояние которого отслеживается OpsMgr («Event ID 1207 - Rule/Monitor "……." will be disabled as it is not remotable»).

Это всего лишь информационное сообщение, которое говорит нам, что рабочий процесс делает то, что он должен, или не делает. В большинстве случаев это Discovery, помеченное, как "not remotable", но целевым классом которого является agentless objects, такой как виртуальный объект компьютер кластера  Windows или Windows Server. Поскольку данные объекты помечены как "not remotable", то они должны быть нацелены на более низкий класс, к примеру "Windows Server Operating System", который не содержит безагентных объектов. К сожалению, это раздражающий и ничего не значащий event  by design.

EVENT ID 10000 OS Discovery

По-умолчанию target для OS Discovery скриптов является класс Windows Computer, DataSource для скрипта – запрос в реестр, либо WMI, который запускается после того, как обнаруживается соотвествующий класс, поэтому мы видим ошибки 10000 по обнаружению WS2008 на WS2012 машинах. Чтобы ошибки ушли, необходимо создать переопределение, отключив обнаружение для класса WS2012.

EVENT ID 1008: The Open Procedure for service "BITS" in DLL "C:\Windows\System32\bitsperf.dll" failed

Возникающая при рестарте  ошибка на серверах управления или серверах, являющихся агентами SCOM "Event ID1008: The Open Procedure for service "BITS" in DLL "C:\Windows\System32\bitsperf.dll" failed" появляется из-за особенностей совместного функционирования компонентов SCOM и операционной системы и не имеет никакого негативного влияния ни на OpsMgr, ни на операционную систему.

Дело в том, что при перезагрузке система начинает проверку и инициализацию всех счетчиков производительности в зависимости от установленных  на сервере служб, а входящий в состав SCOM MOMPerfSnapshotHelper.exe (компонент, несущий ответственность за проверку счетчиков производительности), также начинает работу при старте Health Service. Если счетчики BITS все еще заняты системой, происходит появление данной ошибки, но как только счетчики полностью проверены и инициализированы OS, SCOM успешно завершает начатый им процесс, что видно в procmon

MOMPerfSnapshotHelper.exe  C:\Windows\System32\bitsperf.dll SUCCESS 01.10.2013 12:47:12,6100708 QueryOpen CreationTime: 22.09.2013 4:43:16, LastAccessTime: 22.09.2013 4:43:16, LastWriteTime: 22.09.2013 4:43:16, ChangeTime: 01.10.2013 12:04:18, AllocationSize: 24 576, EndOfFile: 24 576, FileAttributes: A  Domain\AccountName  4700

Успех опроса счетчиков не логируется в Application Log (by design). Соотвествено ошибка – является только сообщением в логе, а не индикатором какой-либо проблемы.

Открывался запрос в продуктовую группу OpsMgr. Группа заявила, что в связи с отсутствием какого-либо негативного эффекта от наблюдаемой ошибки, а так же невысоким распространением ошибки, пересмотр и модифицирование дизайна службы Health Service проводиться не будут.

Если есть подобные ошибки в отношении, к примеру: .Net или WMI - можно попробовать добавить счётчики производительности в Performance Monitor - если всё прошло нормально, то игнорируем данные сообщения. Как правило, такие ошибки не носят регулярный характер, и логируются, при попытке какого-либо приложения выполнить активацию счётчиков для своих целей, через службу.

Windows Server 2016 CTP3 Hyper-V Replica

Сегодня с коллегой провели интересный эксперимент:
связали через Hyper-V реплику узел виртуализации на базе Windows Server 2012 R2 (как основной сервер) и кластер Hyper-V Windows Server 2016 CTP3, как реплику. Такие возможности, если они будут поддерживаемы Microsoft, после выхода релиза Windows Server 2016 RTM, дают большую гибкость.

Исходный сервер и кластер виртуализации находились в разных лесах (использовались Forest trusts).

Немного технических деталей ниже.

Для начала мы настроили реплику со стороны кластера.
 
ПРИМЕЧАНИЕ! обратите внимание на добавление элементов интерфейса Enclosures и отдельный тип Core Resource - Virtual Machine Cluster WMI (см. ниже).
 

 
Вкладка Enclosures предоставляет дополнительную информацию о СХД, подключенной к кластеру.
 

 
На мой взгляд, очень интересное новшество. В этом же разделе можно увидеть узлы виртуализации, выбрав вкладку Servers и физические диски по идее..., выбрав Physical Disks , но диски у меня почему-то не отразились - пока разбираюсь)
 

 
Итак, создадим настройки репликации.
 

 
Создаём VCO и задаём FQDN
 

 

 

 
 

 
Поскольку моя сеть доверенная и это тестовая среда, я не заморачивался с созданием SecurityTag, подробнее читайте тут
 

 
 
ПРИМЕЧАНИЕ! Получаем вот такое предупреждение - это поведение по-умолчанию. Поправим позже.

 
Для развлечения репликой мы выбрали первые попавшиеся VM - два чистых, развёрнутых ранее Template (они не несли никакой нагрузки, не думайте, что мы реплицировали контроллер домена - это НЕПОДДЕРЖИВАЕМЫЙ СЦЕНАРИЙ).
 

 

 

 

 

 

 

 

 
Кажется все идёт неплохо и реплика успешно создалась.

 
 
Собственно реплика в процессе

 
И в итоге процесса мы получили VM, которая успешно реплицировалась в кластер Hyper-V Windows Server 2016 CTP3 с Hyper-V Windows Server 2012 R2 (мы сделали две).
 

 

Теперь дадим команду на Failover в Hyper-v на Windows Server 2012 R2

 

Если машина не выключена, то вы получите предупреждение ниже

 

 

Повторяем операцию

 

 

 

 

Собственно работающая VM на резервном кластере.

 

ВНИМАНИЕ! После репликации на другой сервер с другим Virtual Switch, машина теряет подключение сети - необходимо восстановить его вручную.