Solving administrative challenges
Спросите любого администратора Windows о его проблемах, и в верхней части списка будет большое количество работы и постоянная нехватка времени чтобы сделать ее. Они знают о средствах автоматизации, возможно даже осведомлены о возможностях WMI и Powershell, но у них нет времени чтобы освоить эти технологии. Это позорная ситуация, потому что принято считать, что до 70% бюджета ИТ организации расходуется на то «чтобы все было в рабочем состоянии» (прим переводчика: в оригинале “keep the lights on.”). Автоматизация может сократить расходы из этих 70%, за счет чего освободятся время и деньги для задач дальше по списку «проблем».
Кроме того, возможно, что они интересовались WMI или Powershell и пришли к выводу, что эти инструменты слишком сложны для освоения. Это понятно, особенно учитывая трудоемкость работы с WMI через VBScript, а также отсутствие примеров, которые объясняли бы используемые приемы. Даже меня повергают в ужас некоторые примеры скриптов Powershell размещенные в интернете, что же чувствуют те, кто только начали разбираться с этой темой. Администраторы, отказавшись от использования этих инструментов упускают возможности уменьшить свою рабочую нагрузку, упускаю возможность провести автоматизацию своих процессов.
Снизить планку входа к использованию WMI ставилось целью этой книги. Примеры предоставляемые в ней могут быть использованы без изменений или с минимальным их количеством. Кроме того, вы получите более глубокое понимание WMI, которое может быть использовано для работы с областями ранее недоступными для вашего контроля. PowerShell сконструирован так, чтобы сделать использование WMI проще и понятнее чем в скриптовых языках ранее, PowerShell движок автоматизации от Microsoft, которая, помимо всего прочего, обеспечивает облегченный доступ к богатым наборам инструментов управления, доступных в WMI.
Вместе PowerShell и WMI предоставляют набор проверенных методов, которые позволят вам управлять вашей системой легко и быстро. Вы сможете автоматизировать многие стандартные задачи, которые в настоящее время потребляют слишком много вашего внимания.
Первым делом, опишем проблему которая стоит перед современным системным администратором.
Существует целый ряд вопросов, которые влияют на любую среду Windows, значительного размера
- Увеличение количество систем
- Повышающаяся сложности инфраструктуры
- Растущая скорость изменений
Во второй части главы я покажу, почему PowerShell и WMI обеспечивают большой набор инструментов для решения этих проблем. Получение отдачи от PowerShell предполагает незначительных первоначальных затрат времени на его изучение, особенно при использовании WMI. Изучив язык и автоматизировав ваши ежедневные процессы вы сможете достичь отличной отдачи от затрат времени на процесс обучения.
Глава заканчивается двумя примерами демонстрации мощности этой комбинации технологии. Первый пример показывает, как можно отключить все сервера в центре обработки данных с помощью одной команды, а второй показывает, как вы можете проверить настройки многих машин за один проход.
Давайте начнем с рассмотрения обязанностей современного администратора Windows и проблем с которыми он сталкивается.
1.1 Административные задачи
Администраторы — очень занятые люди. Они, кажется, постоянно должны сделать все больше с меньшим количеством ресурсов. На рисунке 1.1 слева мы видим график снижение стоимости, аппаратного обеспечения. Я, например, недавно приобрел ноутбук с 4х ядерным процессором (HyperThreading позволяет увидеть восемь ядер) и с 16 Гб оперативной памяти, я собираюсь использовать его как свою мобильную лабораторию. Так вот, несколько лет назад, машина с этими параметрами была в среднем сегменте серверов, а не ноутбуков!
То же самое верно для серверов с 4, 8, или даже 10ти ядерными процессорами. В компьютеры можно установить все больше относительно дешевой памяти. Это означает, что все большее число компаний может себе позволить запуск приложений и бизнес-процессов, которые ранее использовались только крупными корпорациями с огромными ИТ бюджетами.
Удешевление мощности аппаратуры приводит к двум другим графикам, они отражают крутой рост сложности инфраструктуры и еще быстрее рост административных расходов на поддержание ее в рабочем состоянии. Постоянное усложнение инфраструктуры и рост затрат на нее, является на данный момент основной проблемой ИТ департаментов.
Для сокращения бюджета нужно сломить кривую роста эксплуатационных расходов и PowerShell с WMI поможет вам в этом. Для начала давайте разберемся – откуда появляется сложность и рост расходов на администрирование?
1.1.1. Слишком много машин
Действительно ли вам нужен каждый сервер что вы создали? Многие, если не большинство организаций имеют слишком много серверов. Это происходит по ряду причин:
- Снижение стоимости аппаратной мощности – это приводит к тому что при высокой загрузке проще докупить новый сервер чем искать как оптимизировать имеющиеся.
- Самостоятельные закупы отделов или закупки под проекты – этот происходит из за вопросов принадлежности сервера, департаменты или «проектники» не хотят чтобы на их серверах кто-то «сидел». Они не желают предоставлять другим свои ресурсы.
- «Одно приложение – один сервер» — разделение приложений так чтобы проблема в одного не влияла на другого, это правило все еще может действовать для критически важных бизнес-приложений, но это не обязательно для второго или третьего эшелона приложений. И безусловно, это не нужно для целей тестирования и обучения.
- Медленная реакция или ригидность ИТ отделов – отсутствие контроля и запущенность процессов в ИТ департаменте приводит к разброду в проектах и беспорядочному изменению систем.
Нагрузка на системного администратора растет быстрее, чем темпы роста мощности машин из-за времени, которое ему нужно затрачивать на переключение внимания между машинами (обычно требуется сделать новое удаленное подключение), дополнительная сложность каждой машины и ее приложений приносятся в жизнь системного администратора.
Виртуализация идущая полным ходом тоже вносит свое. Есть несколько преимуществ виртуализации:
- Сокращается число физических серверов
- Снижается требование к ЦОД организаций, в том числе из за пространства, электроэнергии и затрат на кондиционирование
- Более точно используются мощности физических активов, что ведет к большей отдачи инвестиций
Организация в целом получает выгоду от виртуализации, но нагрузки администратора увеличивается. Если у вас было 100 серверов до виртуализации, и вы устанавили вместо них 4 физических хоста и завиртуалили на них 100 серверов, то у вас получится 104 системы которыми нужно управлять. Кроме того что их стало на 4 больше, сложность увеличится из-за того что платформа виртуализации может ввести другую операционную систему в инфраструктуру или добавить новые инструменты. Увеличение общего количества (физических плюс виртуальных) систем, также означает, что возрастает вероятность происшествий, во время эволюции инфраструктуры.
1.1.2 слишком много изменений
Изменение можно рассматривать как худшую головную боль администратора. К сожалению среды не статичны, изменения происходят всегда:
- Операционная система и приложения получают регулярно патчи
- Выходят новые версии программ
- Пространство хранения нуждается в перенастройке для соответствия меняющимся типовым задачам пользователей.
- Типовые сценарии работы приложений требуют изменений аппаратной части или аппаратной модернизации.
- Виртуализация и другие прорывные технологии изменяют экосистему и создают новые возможности и конфигурации.
Эти проблемы накладываются на десятки, сотни или даже тысячи машин, накладываются на ежедневную активность, такую как мониторинг и резервное копирование.
Эта ситуация не может продолжаться бесконечно. Компании не могут смягчать постоянно растущие расходы на администрирование, сегодняшние экономические реалии запрещают использовать альтернативные механизмы такие как бесконечное увеличение доходов чтобы не замечать рост расходов ИТ отделов. Ситуация должна быть решена за счет сокращения расходов на эксплуатацию, но администраторы не могут сделать это из-за того, что множество изменений приносят новые и новые технологии не снижающие нагрузку и так происходит бесконечно.
1.1.3 Растущая сложность
Сложность — реальная проблема. Она возникает из-за ряда причин:
- Несколько операционных систем несут различные наборы инструментов и терминологию, разница есть даже между двумя версиями Windows.
- Различные типы приложений, таких как базы данных, электронная почта, службы каталогов Active Directory, и веб-приложения, требуют различных навыков, различных инструментов, имеют разные требования и создают разную нагрузку на сервера.
- Многие машины выполняют одинаковые или схожие роли, но незаметные особенности в их реализации, недокументированные возможности увеличивают вероятность ошибки и делают структуру сложнее.
Сложность также нарастает из-за неполноты знаний и навыков самих администраторов. Слишком часто проект вводит новую технологию и от системных администраторов ожидается что они сразу же подхватят и начнут управлять системой. У них есть необходимые навыки? Есть ли у них время, чтобы изучить тонкости привносимой технологии? К сожалению, ответ на оба вопроса часто отрицательный.
Администратор в такой ситуации примет единственно верное решение – он начнет делать так как умеет. Иногда, если новая технология является изменением версии от чего-то уже, администратор продолжит использовать старые методы, даже если в новой версии появился намного лучший способ выполнить задание.
Отсутствие навыков и знаний приводит к ошибкам, и эти ошибки стоят денег, часто их можно рассматривать как потерю дохода для организации. Это ставит под стресс администраторов и приводит к недоверию со стороны руководства бизнеса. ИТ отдел часто исключен из дискуссии о внедрении новых технологий, слишком поздно он узнает о том что руководство решило пойти на изменения их среды, и цикл ошибок повторится вновь.
Кроме того, мало что идут большие изменения вносимые проектами, системные администраторы стоят перед лицом множества мельчайших изменений, необходимых, чтобы держать среду в безопасности и обеспечивать стабильность работы.
1.2 Автоматизация – путь для прорыва вперед
Решением для преодоления этих проблем является автоматизация рутинных операций. Поручить машине делать простую, повторяющуюся работу это то ради чего мы делали их!
Автоматизация понимается по разному. Ниже приведена иерархия автоматизации.
Чтобы внедрить уровень выше этой иерархии нужно ответить на вопрос – «будет ли польза от перехода на более сложный уровень?». Я знаю целый ряд организаций, которым хватает возможностей стандартного инструментарий Windows и несколько инструментов массовой рассылки команд (прим. переводчика: незнаю как точно перевести «a few bulk-editing tools»). Другие пытаются максимально использовать планировщик задач или даже создают ответы на события в журнале. Автоматизация для большинства организаций представляет из себя смесь инструментов командной строки, сценариев, и задач в планировщике.
Следующий вопрос — «Как мы можем автоматизировать мои административные задачи?». PowerShell предоставляет набор инструментов командной строки (называемых «командлеты») которые можно использовать интерактивно вводя в консоль. По мере того как сложность решаемых задач становится больше и амбициознее, происходит появление скриптов. В PowerShell вы можете использовать одни команды, одно написание и один стиль для командной строки и при написании сценариев.
PowerShell прекрасный инструмент (Да, я фанат PowerShell). При необходимости вы можете легко перейти на следующий уровень сложности, и так далее, а WMI будет на самом верху этой лестнцы. (прим переводчика. Richard Siddaway в книге «powershell in depth» написал «если вы не используете WMI в связке с powershell то теряете да 60% мощности»). WMI откроет Вам доступ к стандартному набору инструментария управления системой, которую вы сможете использовать локально или на удаленной машине, потенциально вы сможете работать даже с не Windows системами (прим. переводчика он имеет в ввиду CIM). Сценарии могут быть запущены интерактивно или могут быть запланированы на время. Но прежде чем мы углубимся в подробности нам нужно осмотреть автоматизацию в целом.
В этой книге, мы будем концентрироваться на сценариях как основном средстве автоматизации. Конечно, вы могли бы сделать много из командной строки подключаясь к удаленным машинам. Однако, преимущество сценариев в том что вы можете использовать код повторно, каждый раз экономя время на написание и отладку кода. Эта тема подробно рассматривается в главе 4 книги «PowerShell in practice» издательства Manning 2010. Запланированные задачи и «автоматические реакции на события» слишком сильно зависят от вашей конкретной инфраструктуры, в главе 3 мы начнем рассматривать как вы можете сделать автоматические ответы на события происходящие в вашей системе.
Давайте рассмотрим пример. Предположим вам нужно определить количество свободного пространства на диске С нескольких машин в вашей среде. Один из способов это прийти в ЦОД, подключится к каждой машине по очереди и посмотреть свободное пространство диска С. Записать ответ и повторить для следующей машины.
Немного проще вариант – использовать RDP для подключения к каждой машине и вручную сгружать информацию. Таким образом вы не будете выходить из за своего стола. Но вы по прежнему должны сделать очень много маленьких действий, вы по прежнему теряете слишком много времени.
И решение которое мне нравится – использовать для этой цели PowerShell, код приведен в листинге 1.1. Не волнуйтесь если вы прямо сейчас не понимаете его. Мы вернемся к этому сценарию в главе 6 когда будем рассматривать как управлять дисковой подсистемой.
Пример начинается со списка имен компьютер моей лаборатории. Этот список передается по конвееру в командлет ForEach-Object (foreach) который вызывает Get-WmiObject для каждого сервера из списка с запросом данных о логическом диске С. Затем полученная информация форматируется и выводится в виде таблицы
Листинг 1.1 Определить свободное место на диске:
"dc02", "W08R2CS01", "W08R2CS02", "W08R2SQL08", "W08R2SQL08A", "WSS08" | foreach {
Get-WmiObject -Class Win32_LogicalDisk -ComputerName $_ -Filter "DeviceId='C:'" } |
Format-Table SystemName, @{Name="Free"; Expression={[math]::round($($_.FreeSpace/1GB), 2)}} -auto
Свободное пространство пересчитывается из байтов в гигабайты, чтобы сделать результаты более понятными. Обратите внимание что PowerShell понимает сокращение GB, а также KB, MB, TB и PB.
Результат работы скрипта выглядит следующим образом:
SystemName Free
---------- ----
W08R2CS01 119.04
W08R2CS02 118.65
W08R2SQL08 114.8
W08R2SQL08A 115.17
WSS08 111.41
DC02 118.53
Ряд усовершенствований можно внести в этот сценарий:
- Поместить имена компьютеров в CSV файл (как мы будем делать в листинге 1.4)
- Добавить результат работы в Excel, или базу данных чтобы можно было видеть тенденцию изменения места на диске
- Запланировать выполнение задачи в планировщике
У меня работает такой сценарий с двумя первыми улучшениями. Он регулярно сообщает о месте на дисках, можно посмотреть тенденции. После написания у меня есть инструмент который можно запустить за несколько секунд, опросит каждую машину сам и вернет информацию. В случае чего я могу его дописать
Мне понадобилось всего несколько минут чтобы написать его и я экономлю время когда я запускаю его снова и снова. Именно таким способом PowerShell помогает сэкономить время. Jeffrey Snover, архитектор PowerShell написал — «Я твердо верю, что экономика определяет, что люди делают и что они не делают. PowerShell разработан с нуля, чтобы быть расширяемой, высоко уровневой, задаче ориентированной абстракцией, удешевляющей расходы на администрирование и поддержку.» Полный текст его статьи, (тут уже переведено) «Семантический разрыв» доступен на странице Windows Powershell blog по адресу blogs.msdn.com/b/powershell сделайте поиск по слову «semantic gap» и вы натолкнетесь на эту статью.
прим переводчика здесь мной пропущено несколько разделов
1.3.3 Сломать кривую роста
На рисунке 1.1. мы видели, непрерывный рост сложности организации и затрат на администрирование. Это непрерывное увеличение сложности и расходов рано или поздно приведет к потере баланса и остановке роста из-за расходов на управление, нужен способ чтобы сломать этот рост.
PowerShell может помочь остановить рост расходов, обеспечивая следующее:
- предоставляет набор инструментов интерактивной работы с сервером и приложениями
- Работает во всех системах Windows (прим переводчика: в оригинале применено слово estate точный перевод – поместья, владения. Подразумевается, что это core технология Microsoft и все системы так или иначе имеют командлеты)
- Предоставляет один универсальный подход работы с разными системами (прим переводчика: все командлеты однообразы, не нужно изучать список ключей консольной утилиты)
- Встроенные возможности удаленного управления
- Встроенные возможности для дальнейшего усложнения автоматизации
PowerShell методы повышающие производительность и эффективность. А с помощью PowerShell и WMI вы можете рассчитывать на дальнейшие повышения вашего роста контроля над системой.
P/S/ Итог: если ваша инфраструктура стоит перед лицом все большего усложнения, то стоит задуматься о переходе на новый уровень автоматизации. Я много слышу от друзей о усложнении инфраструктуры, постоянное давление от маркетинговых отделов, постоянное изменение систем. Лично я такое давление ощущаю, сейчас ищу способ создать автоматических ботов для админских задач.
Комментарии (11)
pvs043
28.05.2016 14:57Перевод немножко «корявый», но смысл передан верно.
Николай, ждём статей про DSC — вот где будущее PowerShell!pak-nikolai
28.05.2016 15:01-1чтонибудь посоветовать можете из ресурсов для перевода? ознакомлюсь
pvs043
29.05.2016 04:11Не совсем в формате Хабра (видео), но перевод шикарный (см. транслит).
Джейсон Хелмик, Джеффри Сноувер: «Начало работы со службой настройки требуемого состояния PowerShell (DSC)»
https://mva.microsoft.com/ru/training-courses/-powershell-dsc--8672?l=dlwgB3wFB_1704984382
Перевода второй части на русский пока нет…
https://mva.microsoft.com/en-US/training-courses/advanced-powershell-desired-state-configuration-dsc-and-custom-resources-8702?l=3DnsS2H1_1504984382
pak-nikolai
28.05.2016 15:22сделаю ревизию статьи через пару часов.
после перевода некоторое время находишься под влиянием языка оригинала, т.к. стремишься передать правильно мысль. Это приводит к странным англоязычным оборотам когда одну мысль пишут в два предложения.
amarao
30.05.2016 11:23Уродливый инструментарий невозможно исправить книжками в которых эта уродливость объясняется подробнее.
pak-nikolai
31.05.2016 06:53сразу прошу прощения, т.к. формат общения через пост то я Вас мог неправильно понять. Я понял что вы вообще против пошика, может быть Вы просто не посмотрели на него с другой стороны.
почему же он уродливый?
он молод, не имеет еще широкой известности, многие скрипты портированные с VBS делают его ужасным.
ну и что, я лично увидел в нем возможности например такие:
1. берем список сервисов почтовика и проверяем все ли запущены сейчас
get-content "c:\echange-service.txt" | get-service | where {$_.status -eq 'stopping'}
2. быстро определить маштаб заражения cryptlocker`ом
dir "d:\users_homefolder\" -recurse -file | where {$_.extension -eq '.lock'}
это намного лучше чем парсить в командной строке. и намного быстрее. или вот такие штуки
3. получить все патчи вставшие на систему за последние 5 дней
get-hotfix | where { $_.installedon -gt (get-date).adddays(-5) }
4. в сессии на удаленную машину которая все никак не может перезагрузится вводим, и видим что там отрабатывает windows installer
Get-EventLog 'system' | select -first 20
я согласен что мозгу трудно принять после
for %%
потому что модель другая, я довольно долго привыкал что тут все по другому, первые мои статьи на хабре посвещены именно тому что идеология у пошика другая, он не плох, он просто другой. И семантический разрыв он закрывает кое где полнее.
вот выдержка, взято отсюда Создание объектов и вывод данных объектами:
вставка от переводчика — Стиль поша отличается от классического языка программирования, пош это язык администрирования, автоматики, и «управления большими блоками». Вам нужно стремится к максимальной простоте и понятности. Раньше, вы брали текстовый вывод команды и парсили ее, и это было правильно. В поше вы делаете объект и оперируете с объектом. Разница колоссальная.
Пример — вам надо посмотреть нетбиос и проанализировать некоторые данные. Ниже пош стайл:
# делаем функцию Function Get-NBTName { # получаем консольный вывод команды NBTSTAT, сразу же выкидываем ненужное $data=nbtstat /n | Select-String "<" | where {$_ -notmatch "__MSBROWSE__"} # обрезаем каждую строку от мусора $lines=$data | foreach { $_.Line.Trim() } # расщепляем кажду строку на массив элементов по пробелу # то что получилось помещаем в хэш таблицу формируя объект $lines | foreach { $temp=$_ -split "\s+" [PSCustomObject]@{ Name=$temp[0] NbtCode=$temp[1] Type=$temp[2] Status=$temp[3] } } }
теперь делаем вызов функции, сортируем и после автоформатируем например так:
PS C:\> Get-NBTName | sort type | Format-Table –Autosize
на выходе получаем:
Name NbtCode Type Status ---- ------- ---- ------ MYCOMPANY <1E> GROUP Registered MYCOMPANY <00> GROUP Registered MYCOMPANY <1D> UNIQUE Registered CLIENT2 <00> UNIQUE Registered CLIENT2 <20> UNIQUE Registered
Итого на выходе функции Get-NBTName объекты которые можно передавать, сортировать, делать выборку и т.п. Никаких for%%.
Можно возразить — ну и что, в начале ведь парсинг был. Ответ — в пошике вы парсите 1 раз — на входе от тулзы выдающей строки, а в командной строке вы парсите всегда, на выходе входе каждой функции. Вам придется делать парсинг каждый раз когда вы получаете вывод от nbtstat потом передаете это в ping потом пытаетесь сделать например tracert и каждый раз вам придется перебирать строки.
zolti
30.05.2016 13:06Николай, спасибо за статью. Приятно видеть, что powerhell освящают и на русском здесь. Однако перечитывать текст все же стоит перед публикацией, ошибок и помарок весьма много. Плюс адаптацию на русский можно провести более удачно.
В любом случае, спасибо вам, материал полезен.pak-nikolai
30.05.2016 19:26я его раза три переписывал побоялся еще переделывать чтобы не уже не начать искажать мысль Вилсона
предыдущую статью тоже перепиливать не стал из за этих же причин, иначе придется ставить уже свое авторство ))))
Мысль сама по себе интересна. Облака потому и наступают что сулят повышение качества при снижении издержек, а как этого достичь — повышение автоматики. Вилсон предлагает фактически создавать среды с реакцией на события, еще чуть чуть и появятся ремонтные боты. Они собирают в одно целое журнал, разные службы и wmi. если подумать то можно очень сложную автоматику написать. я сейчас пытаюсь разобраться как сделать ремонтника восстанавливающего винду после кривых обновлений.pvs043
31.05.2016 19:04> среды с реакцией на события, еще чуть чуть и появятся ремонтные боты
Уже реализовано как раз в PS Desired State Configuration!
Смысл технологии: создаётся текстовое описание конфигурации серверов/систем на PS (которое удобно хранить на сервере DSC Pull и в системе контроля версий). Затем просто настраиваем локальных клиентов DSC Windows/Linux/Network Hardware(!): «вы будете фермой MS SharePoint, вы будете Web-серверами в Интернет, а „железки“ получат настройки маршрутизации».
Далее конфигурация применяется к «голым» системам и получаем например готовый лес Active Directory, Exchange, SharePoint и т.д. :) Самое главное, что клиент DSC (встроен в Windows PS) периодически проверяет текущее состояние сервера и производит автоматическое исправление и восстановление: роли/фичи/файлы/службы/реестр и т.д.
Ссылки на авторские учебные курсы по PS DSC на MVA см. выше в моем комментарии, документация по DSC здесь: https://msdn.microsoft.com/en-us/powershell/dsc/overview.
Стоит отметить, что проект получил бурное развитие после релиза сайта http://www.powershellgallery.com/ и PowerShell 5.0. Официальный Блог разработчиков: https://blogs.msdn.microsoft.com/powershell/2016/05/18/dsc-resource-kit-anniversary-release/
million
Вы хоть заголовок поправьте. А то какая то «атоматизация» — это что вообще?
pak-nikolai
спасибо