С выпуском System Center Virtual Machine Manager 2012 у нас появилась возможность создавать так называемые сервисы: т.е.
производить виртуальные машины не по отдельности или даже из шаблонов, а комбинировать разные профили, шаблоны, машины, а затем настраивать взаимосвязь между ними.
виртуальное оборудование.
Посмотрев достаточно выступлений на TechEd, прочитав статьи и книги и, конечно же, получив волшебное задание от начальства на одном из проектов, я решил, что имеющихся в SCVMM средств достаточно для создания полноценного сервиса-песочницы, т.е.
набор виртуальных машин, изолированных от остальной инфраструктуры предприятия, но в то же время беспрепятственно взаимодействующих друг с другом.
Но все оказалось не так гладко и красиво, как ашапо на демонстрациях, так что приглашаем вас зайти под кат и получить дозу подачи документов.
Начнем с того, что сервис-ориентированная облачная идеология Microsoft практически идеально вписывается в задачу создания песочницы: вот, пул ресурсов, вот, песочница, песочница работает в облаке, люди, например разработчики, сами используют эту песочницу через портал самообслуживания, создают, удаляют, масштабируют при необходимости, получают отчеты о потреблении ресурсов, им не важно, на каком оборудовании работает песочница, как она резервируется или кем управляется гипервизор .
Но когда дело доходит до практики фактической автоматизации развертывания сервисов, возникают ограничения.
Чтобы объяснить их более наглядно, обращусь к известному и в то же время избитому образовательному приложению от Microsoft — Зоомагазин .
Net , кстати, уже 4-я версия.
Pet Shop — это обычное трехуровневое клиент-серверное приложение: есть сервер СУБД, есть сервер приложений и есть веб-интерфейс, позволяющий потенциальным покупателям зайти и выбрать попугаев через браузер.
Итак, когда мы развертываем это приложение как облачный сервис, мы: 1. Разворачиваем три виртуальные машины, пару пустых, одну с SQL-сервером, они в дальнейшем станут нашими линками; 2. Установите базу данных приложения на SQL-сервер и зарегистрируйте пользователей; 3. Развернуть пакет App-V с приложением магазина на сервере приложений, настроить строки подключения к SQL-серверу; 4. Устанавливаем веб-страницы на веб-морду и настраиваем веб-приложение для подключения к серверу приложений.
Как на самом деле происходит развертывание? Первым шагом при развертывании Virtual Machine Manager является создание виртуальной дискеты и запись на нее.
файл ответов и когда виртуальная машина развертывается, она читает этот файл ответов, присваивает себе имя, устанавливает параметры сетевого интерфейса и даже включает себя в домен Active Directory. На втором этапе SCVMM устанавливает на виртуальные машины свой агент и службы интеграции, а на третьем создает ISO-образ с приложениями, базами данных и другими скриптами конфигурации, монтирует этот ISO-образ в виртуальный диск и начинает с него установку приложений.
Как видите, взаимодействие с виртуальной машиной происходит только с помощью примитивных вещей: виртуальной дискеты и виртуального DVD, поскольку установка агента, как и установка служб интеграции, производится также из соответствующего ISO-образ на диске.
Как будто? Да, но не так.
Дело в том, что чтобы собрать строку подключения к SQL-серверу, нужно как минимум знать имя этого SQL-сервера.
Чтобы собрать строку подключения для приложения, вам также необходимо знать адрес сервера этого приложения.
Между тем, в System Center Virtual Machine Manager 2012 существует три способа установки имени сервера: 1. Задайте его просто как текст, например «SQLServer»; 2. Задайте его шаблоном с цифрами, например «SQLServer##», в этом случае при создании первого сервера SCVMM присвоит ему имя SQLServer01, второго — SQLServer02 и т.д.; 3. Задайте для него переменную, например «@SQLServer@», в этом случае администратору перед развертыванием придется ввести в диалоговое окно «SQLServerForPetShop» или что-то подобное, что впоследствии станет именем сервера.
Первый вариант мы отвергаем сразу, поскольку исходим из того, что сервисов у нас много, а значит много машин с одинаковым именем, а иметь машины с одинаковым именем плохо.
Второй вариант хорош, но появление цифр в конце исключает детерминированность сервера.
Проще говоря, по ссылке 2 мы не знаем, какой именно номер SCVMM присвоен ссылке 1. На самом деле мы знаем, что там вначале стоит SQLServer, а потом 01? 05? Или, может быть, 25? Третий вариант, бесспорно, хорош, но в этом случае лично администратору приходится заботиться, во-первых, об уникальности имен серверов, а во-вторых, о соответствии имен серверов принятому в организации соглашению об именовании.
В общем, получается, что все три варианта существуют, и все три плохие.
Как Microsoft рекомендует выходить из подобной ситуации? Но ни в коем случае.
Эта картинка со страницы 245 книги.
Эйдан Финн Microsoft Private Cloud Computing, опубликованная Sybex, наглядно показывает, что для того, чтобы развернуть сервис Petshop, нужно посмотреть глазами в верхнюю часть экрана, увидеть надпись MidSvr01 и записать эти слова ручками в поле lobComputerName. 
Причем такое переписывание букв с экрана на тот же экран, видимо, является официальной позицией Microsoft, которую повторяют, например, Здесь , в блогах на Technet.
То есть снова : предлагают увидеть на экране строку и ввести эту строку ручками на этом же экране .
Это приемлемо для нас? Ну конечно нет! Информация появляется только в одном месте, необоснованное дублирование информации чревато ошибками, и этим подходом мы будем пользоваться чуть реже, чем никогда в жизни.
Вернёмся в нашу песочницу.
Предположим, у нас есть контроллер домена в лесу Active Directory и сервер, который является членом этого домена.
Теоретически этого достаточно при условии, что услугу можно масштабировать, т.е.
дублировать этот рядовой сервер домена снова, снова и снова.
Формулируя техническое задание на систему-песочницу, можно сказать, что система должна содержать контроллер домена Active Directory, не связанный с другими лесами никакими отношениями, в том числе доверительными, а также система должна содержать сервер, входящий в активный домен.
Каталог, который можно было тиражировать без каких-либо дополнительных усилий.
При этом при желании мы можем перейти на сервер Exchange, SQL Server и многое-многое другое.
Создать контроллер домена Active Directory из SCVMM непросто: контроллер домена не поддерживает виртуализацию приложений App-V, поэтому мы будем устанавливать контроллер домена из командной строки.
Есть утилита dcpromo, которая создает домен, лес или даже вселенную, и, говорю вам, несмотря на различные статьи типа «Конец dcpromo настал, да здравствует PowerShell!» dcpromo сохраняется в Windows Server 2012, но только как инструмент командной строки.
Об этом можно почитать, например, Здесь .
Обратите внимание на строку: Если ты бежишь dcpromo/автономный из командной строки вы по-прежнему можете выполнять автоматическую установку с использованием Dcpromo.exe. То есть автоматическую установку можно прекрасно использовать в Windows Server 2012, а это именно то, что нам действительно нужно.
Хотя, конечно, мы все любим PowerShell неугасающей любовью, а по поводу нововведений в server 12 у меня даже есть пара статей.
Но в целях совместимости мы используем файл ответов, поскольку он работает как в 2008R2, так и в 2012. Итак, чтобы вызвать контроллер домена Active Directory, мы запустим этот cmd-файл, привязанный к профилю приложения в службе песочницы:
Обратите внимание, что все начинается с самого начала%systemroot%\System32\WindowsPowerShell\v1.0\powershell.exe Set-ExecutionPolicy Unrestricted %systemroot%\System32\WindowsPowerShell\v1.0\powershell.exe .\CreateAnswerFile.ps1 -Domain %1 dcpromo /unattend:%systemroot%\Temp\dcpromo.ini shutdown -r -t 30
Set-ExecutionPolicy Unrestricted
По той простой причине, что дальше у меня идут неподписанные PowerShell-скрипты.
Скрипты PowerShell возможно и нужно знак: от этого зависит ваша безопасность и безопасность вашей организации.
Вроде бы здесь уже было пару тем о том, как подписывать, но если нет, то я с удовольствием опишу этот забавный, но поучительный процесс.
Теперь посмотрите, называется некий скрипт CreateAnswerFile.ps1 , которому в качестве входного параметра задается домен.
Вот сценарий: Param ([string]$Domain)
[Reflection.Assembly]::LoadWithPartialName(“System.Web”)
Enable-PSRemoting -force
import-module servermanager
add-windowsfeature DNS
$RandPassLength = [int] 30
$DSRMPass = [System.Web.Security.Membership]::GeneratePassword($RandPassLength,2)
$SafeModePWD = $DSRMPass
$NetBIOSName=($Domain.Split(".
")[0]).
ToUpper()
$DCPromoFile = @"
[DCINSTALL]
ReplicaOrNewDomain=Domain
NewDomain=Forest
NewDomainDNSName=$Domain
ForestLevel=4
DomainNetBIOSName=$NetBIOSName
DomainLevel=4
InstallDNS=Yes
ConfirmGc=Yes
CreateDNSDelegation=No
DatabasePath=`"C:\Windows\NTDS`"
LogPath=`"C:\Windows\NTDS`"
SYSVOLPath=`"C:\Windows\SYSVOL`"
RebootOnCompletion=No
SafeModeAdminPassword=$SafeModePWD
"@
$DCPromoFile | out-file C:\windows\temp\dcpromo.ini -force
Но еще раз обратите внимание, что у меня здесь %windir% как C:\windows, вряд ли у вас будет иначе, но я все равно должен вас предупредить.
Хорошо, наш контроллер домена заработал, нам он нравится.
Но для того, чтобы определенный сервер был включен в состав этого домена, он должен сначала получить адрес этого контроллера домена, а во-вторых, получить настройку на его сетевом интерфейсе: этот контроллер домена должен быть установлен в качестве его DNS-сервера, и в-третьих, получить команду на присоединение к домену.
Как мы можем получить IP-адрес DNS-сервера? Ведь по условиям задачи мы находимся в изолированной отовсюду сети и не знаем ничего, даже имени контроллера домена, который развернут параллельно с нами.
Есть выход. Помните, когда-то был развернут SCVMM — гостевой агент? Итак, при развертывании этого гостевого агента внутри него совершенно волшебным образом появляется файл настроек с конфигурацией сервиса.
В этом файле содержится информация, во-первых, жутко урезанная, во-вторых, доступная только системной учетной записи (SYSTEM).
Но это, как вы понимаете, файл не сохранит, потому что как только информация появилась, ее невозможно уничтожить.
Из этого файла, который очень похож на XML, за исключением первых 16 бит, мы извлекаем имя контроллера домена.
Да-да, тот самый, который генерировался динамически при развертывании сервиса.
Имея имя, мы можем преобразовать это имя в IP-адрес, верно? Нет, это не правильно, потому что у нас нет DNS-сервера, который бы нам ответил, мы просто не знаем, к кому обращаться.
Поэтому призываем на помощь старый добрый протокол NetBIOS, который понимает, что такое широковещательный запрос на разрешение имени.
Другими словами, мы, зная имя сервера, громко кричим в сеть: «Давай такой-то, откликайся!» А он отвечает: «Вот я, только не бейте меня, пожалуйста!» Берем его адрес как DNS-сервер, а потом включаем себя в домен.
Миссия выполнена .
Учитывая, что этот скрипт выполняется каждый раз при масштабировании сервиса, мы можем запускать его бесконечно и таким образом наша песочница превратится в «контроллер домена + (пустой_сервер x N)».
Ну а теперь, пожалуйста, сам скрипт: Start-Sleep 90
$scvmmGuestAgentProcess = Get-Process ScvmmGuestService
$guestDirectory = $scvmmGuestAgentProcess.Path
$settingsDirectory = (Split-Path $guestDirectory -Parent)+"\Settings"
$uname = [System.Security.Principal.WindowsIdentity]::GetCurrent().
Name takeown /F $settingsDirectory /A /R /D Y $goalStateFile = $settingsDirectory + "\DesiredGoalState.dat" $rule = $uname+":(R)" icacls $goalStateFile /grant $rule $goalStateText = [string](Get-Content $goalStateFile) $goalState = [xml]($goalStateText.Substring($goalStateText.IndexOf("<"))) $computerNames=($goalState.GuestGoalState.ServiceSettings.ServiceSetting | Where-Object {$_.name -eq "ServiceVMComputerNames"}).
value $namesArray = $computerNames.Split("[]") $dCName = $namesArray[[array]::IndexOf($namesArray,"Domain controller")+1] $dCIP = (([System.Net.Dns]::gethostentry($dCName)).
AddressList | Where-Object {$_.AddressFamily -eq "InterNetwork"}).
IPAddressToString $wmi = Get-WmiObject win32_networkadapterconfiguration -filter "ipenabled = 'true'" $wmi.SetDNSServerSearchOrder($dCIP) $domain = ($goalState.GuestGoalState.ServiceSettings.ServiceSetting | Where-Object {$_.name -eq "Domain"}).
value
$domainUserName = $domain+"\administrator"
$domainPassword = "Pa`$`$w0rd"
$credentials = new-object -typename System.Management.Automation.PSCredential -ArgumentList $domainUserName,($domainPassword | ConvertTo-SecureString -AsPlainText -Force)
Add-Computer -Credential $credentials -DomainName $domain
Restart-Computer
Обратите внимание, что здесь четко указан мой логин/пароль.
Совершенно очевидно, что в целях безопасности вам придется их спрятать.
Итак, включив этот скрипт в профиль приложения, и выполнив его при развертывании на N серверов, мы получим свою песочницу.
Теперь мы можем модифицировать нашу песочницу как угодно, писать туда программы, удалять программы оттуда, создавать пользователей, удалять их, изменять схему, атрибуты, делать все, что душе угодно.
Ну а если вдруг испортим, то удалим песочницу и за полчаса создадим новую! Нам не составит труда создать даже две песочницы.
Это просто рай для разработчиков и тестировщиков! Еще рекомендую почитать блог Иди Финна, он там пишет очень очаровательные вещи.
Теги: #Облачные вычисления #PowerShell #active каталог #Active Directory #System Center #scvmm #диспетчер виртуальных машин
-
Я Хочу Такую Картинку
19 Oct, 24 -
Повышение Сознательности Граждан
19 Oct, 24 -
Хабраобразование. Какой У Тебя Уровень?
19 Oct, 24
