обновление серверов через Orchestrator 2012 (часть 1)
Привет.
Что больше всего любит делать системный администратор?
Перегружать ночью сервера?!
Представьте, что вам нужно выполнить установку обновлений по очень гибкому графику.
Например, такой вот вариант (и это 10%, или 1%, или 0.1 % от общего количества серверов):
имя сервера | время для обслуживания |
Server001 | Понедельник 11:00-13:00 |
Server013 | |
Server014 | |
Server013 | |
Server022 | |
Server016 | |
Server023 | Четверг 3:00-4:30 |
Server035 | |
Server046 | Четверг 20:00-22:00 |
Server012 | |
Server003 | |
Server005 | Четверг 20:00-21:00 |
Server111 | Пятница 14:00-16:00 |
Server234 | Суббота 00:00-2:00 |
Server012 | Воскресенье 01:00-3:00 |
У каждого сервера свой список ответственных лиц. И в случае, если на сервере есть доступные для установки обновления, этим лицам нужно написать заранее, предупредить о планируемых работах. А потом еще и написать, что все прошло удачно.
Ну очень не хочется делать все это вручную.
А вам? Как же избавиться от этой рутины?
WSUS или SCCM? Расписание еще можно попробовать, но оповещение?
Нам поможет Orchestrator.
Источник данных.
Где мы можем хранить информацию по данному процессу? Можно использовать файл csv, базу данных, да хоть Active Directory (расширяйте схему, добавляйте поля к классу, но не советую 🙂 ). В наборе Orchestrator имеются инструменты для эффективной работы с базами данных. Поэтому давайте создадим базу данных и таблицу для наших нужд. Можно использовать тот же SQL сервер, где хранится база Orchestrator.
Открываем Microsoft SQL Management Studio. Подключаемся к нужному серверу с правами, достаточными для создания базы данных, открываем New Query и выполняем следующий запрос:
-- Создание базы
USE [master]
GO
CREATE DATABASE [Orchestrator_data] ON PRIMARY
( NAME = N'Orchestrator_date', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\Orchestrator_data.mdf' , SIZE = 2048KB , MAXSIZE = 2GB , FILEGROWTH = 10% )
LOG ON
( NAME = N'Orchestrator_date_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\Orchestrator_data_log.ldf' , SIZE = 1024KB , MAXSIZE = 2GB , FILEGROWTH = 10%)
GO
--Создаем таблицу
USE [Orchestrator_data]
GO
CREATE TABLE [dbo].[t_Orch_Patching_Server](
[ServerName] [nvarchar](50) NOT NULL,
[DayOfWeek] [nvarchar](10) NULL,
[Time] [nvarchar](10) NULL,
[Order] [int] NULL,
[E-mail IT] [nvarchar](max) NULL,
[Type] [nvarchar](10) NULL,
[NeedToUpdate] [int] NULL,
[Error] [int] NULL,
[ErrorMesg] [nvarchar](max) NULL,
[InstalledUpdatesResult] [int] NULL,
[NeedToReboot] [int] NULL,
[LastUpdateTime] [datetime] NULL,
[LastCheckTime] [datetime] NULL,
[E-mail business] [nvarchar](max) NULL,
[Descr] [nvarchar](50) NULL,
[EndTime] [nvarchar](10) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
Нажимаем F5 и готово!
Да, полей много, но мне кажется, нужно будет еще добавить. 🙂
Не забываем про права доступа, достаточно удобно дать права той же учётке, от которой работает ваш Orchestrator:
Дальше будет интереснее!
Александр Петлевой
[…] « обновление серверов через Orchestrator 2012 (часть 1) […]
[…] Первая часть […]
Неее, SCCM в данном вопросе рулит. Деплоить обновления Orchestrator-ом, ИМХО, достаточно проблематично — слишком много условий.
А как вы рассылаете оповещение о предстоящих работах?
А кому? У нас есть опубликованный список согласованных окон обслуживания для каждого сервера.
У вас такой подход к облуживанию, он просто другой, но он тоже очень хороший. И вам действительно достаточно возможностей SCCM или WSUS.
Тут же рассматривается задача с оповещением. И оповещение, как и сами работы, будут только в случае доступных обновлений. Если их нет, нет оповещений, как и прерывания сервиса.
P.S. Все ваши пользователи помнят, что в четверг в 23-00 у вас недоступен сервис ПОЧТА? И программисты, у которых в «самый важный момент», а другого не бывает, около 9 вечера в пятницу, перегрузится «очень критичный для разработки» сервер.
А так утром пришло письмо и все тылы прикрыты.
Спасибо за интерес с статье! 😉
Некоторые системы просто так не перезагрузишь — сначала надо выполнить какие-то действия по их корректной остановке, провести проверки и т.п. К сожалению, SCCM тут не поможет.
Абсолютно верно. Хотя и не рассматривается в рамках этой статьи.
[…] Первая часть […]