Быстрое развёртывание контейнеров из шаблона с 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 - если всё прошло нормально, то игнорируем данные сообщения. Как правило, такие ошибки не носят регулярный характер, и логируются, при попытке какого-либо приложения выполнить активацию счётчиков для своих целей, через службу.