`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Александр Кулаковский

Строим «облако». Часть Вторая. Стандартизация.

+66
голосов

В предыдущих публикациях я постарался рассказать об общепринятой терминологии и основных принципах построения облачной среды, представить свое видение важности использования виртуализации в облачных инфраструктурах. В этой же я хочу описать достаточно легкий, но важный этап в переходе на сервисо-ориентированную модель ИТ — стандартизацию.

Имеются два ключевых момента, ради которых необходимо по максимуму стандартизировать всю инфраструктуру перед миграцией в «облако»:

  • последующая автоматизация. Уровень автоматизации прямо пропоорционально зависит от стандартизации, так как при стандартизованной инфраструктуре автоматизация рабочих процессов упрощается в разы;

  • администрирование. В некоторых ситуациях администраторам все же приходится «спускаться» на инфраструктурный уровень, дабы, к примеру, собрать журналы с ОС или IML в случае сервисного события или просто в целях мониторинга. В стандартизованной инфраструктуре администратор всегда знает, где установлено оборудование или до какой степени обновлена ОС, соответственно, эффективность его работы повышается.

Прежде чем перейти к деталям, предлагаю принять за аксиому: стандартизация инфраструктурных сервисов (DHCP, AD/LDAP, DNS, NTP, развертывание сервера, контроль версий и т.д.) является первым и важнейшим условием для построения облачной среды и добавления в нее любого активного оборудования. Об этом говорится в документации к любому ПО, которое формирует ядро облака. Многие дистрибутивы также включают специальные мастера для проверки соблюдения всех инфраструктурных и аппаратных требований. Такие приложения могут быть очень пригодиться в стандартизации на всех уровнях.

Итак, по порядку:

Стандартизация инфраструктурных сервисов заключается в разработке и реализации единой конфигурации для каждого сервиса. Если, к примеру, у вас есть несколько региональных офисов со своим активным оборудованием и собственными субдоменами в древе AD, то эту практику следует распространить на все региональные офисы. В свою очередь, распознавание имен необходимо для всех компонентов инфраструктуры — как прямое, так и обратное. Если у вас есть NTP-сервер, синхронизируйте через него все компоненты инфраструктуры, а не только бизнес-критичные. Результатом станет минимизация «нюансов» в эксплуатационных процессах, а значит, их можно будет легко автоматизировать.

Стандартизация протоколов подразумевает их унификацию. К примеру, для мониторинга глобально выбран протокол WBEM. В этом случае на всех коммутаторах будет открыт порт 5989, а на всех ОС — установлены агенты. Такой же принцип используется при стандартизации и развертывании серверов. К примеру, установка ОС глобально работает по РХЕ-протоколу. Успешным результатом этого этапа стандартизации будет существенное повышение эффективности автоматизации, так как «портфолио» приложений промежуточного слоя и технологических карт будет уменьшено в разы, а автоматизация, в основе которой и лежат технологические карты, станет более предсказуемой.

Версионная стандартизация необходима для минимизации рисков предоставления и обслуживания сервисов. Задача на этом этапе одна: создание и соблюдение базового уровня по версиям микропрограмм, драйверов и ПО промежуточного слоя, согласно спискам совместимости от производителей. Для удобства ее решения существует множество инструментов для организации репозиториев с прошивками, драйверами и сопутствующими приложениями. С их помощью можно и конфигурировать базовые уровни как таковые, и централизовано выполнять обновление по любым схемам (с тестовой обкаткой на одной системе и пр.)

Последний этап я называю организационной стандартизацией. Его задачей является определение единой системы имен серверов, LUN, конфигураций, резервных копий, а в итоге — и сервисов. Результат организационной стандартизации только один — облегчение жизни администраторам, а, следовательно, и повышение эффективности их работы.

Общий итог: стандартизацию достаточно легко реализовать в любой среде, потому что она не требует финансовых вложений. Главным результатом, помимо повышения эффективности и оптимизации работы компонентов, будет «предсказуемость» работы инфраструктуры и ее сервисов, а значит — снижение рисков.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+66
голосов

Напечатать Отправить другу

Читайте также

В этой же я хочу описать достаточно легкий

опять пропущено строгое описание рамок применимости!

, но важный этап в переходе на сервисо-ориентированную модель ИТ — стандартизацию.

Если для организации ИТ - стандартизация не является сложной, то о каких организациях идёт речь?

Павел,

рамки применимости - любая ИТ инфраструктура любого предприятия. Я придерживаюсь мнения, что любая инфраструктура должна быть стандартизирована, тем более, что такой процесс, как стандартизация, не зависит от сферы деятельности компании и эффективна в ИТ-инфраструктурах любого объема.

Стандартизация не сложный процесс в плане реализации, так как не требует вложений, а просто времени Администраторов.

С первым абзацем полностью согласен. Второй - требует уточнения. Вполне возможен зоопарк оборудования и програм и невозможность его обновить как по финансовым, так и по технологическим причинам. Да и время Администраторов - это тоже не бесплатный и не бесконечный ресурс. Вы сами приводили примеры при обсуждении первой статьи!
Оттуда же и напомню свой вопрос: [... нужно выстраивать сервисно-процессную модель ИТ, налаживать каталог сервисов и тренировать службу поддержки. Нет финансов на консалтинг? А на "облака" есть?]
"Стандартизация" стоит даже перед "сервисно-ресурсной моделью (СРМ)ИТ". И я бы не стал говорить о том, что возможен переход к облачным вычислениям, минуя СРМ. Иначе рамки применимости сужаются до очень специфических организаций, для которых "легко" и "не сложно" провести стандартизацию инфраструктуры. Вот что я имел в виду.
Читаю сейчас книгу Николаса Карра "Великий переход: что готовит революция облачных технологий". Он допускает обобщения, но всегда об этом предупреждает.

Как знакомо, аж плакать хочется.
Я 2 года назад пришёл в компанию где серваки обзывают aldebaran, sigma, almach, rastaban (короче звёзды и созвездия).
всё это время пытаюсь вдолбить в голову определённых админов что называть сервера стандартно (согласно ролям SRV_xx_GW_xx,SRV_xx_HV_xx ...), всё как об стену горох :( .
И жизнь их ничему не учит, даже когда сам не может без ошибок 3 раза подряд написать "alioth" (потому что произносится совсем иначе). Руки опускаются. Уже до истерики доходит, аргументы не действуют, одни маты остались, а им ничё страшного. Продолжают называть всякими арктурами. Зато весело.

Как я Вас понимаю:) прошел через это сам...

А когда в одном сегменте сервер в домене( со всеми политиками и иными вытекающими), а в другом - нет. Там snmp мониторинг с дефолтными комьюнити, а другом месте - WBEM по секьюрному порту, но не работает потому, что не синхронизированы часы по NTP...эх:)

Не далее как сегодня видел 8 блейд-серверов в 1-й корзине названных alpha, beta, gamma, delta, omega, bravo, charlie...

Круто :)
Это наверно чтоб враг не догадался.

а луны надо было цифрами назвать:) просто 1,2,3,4...

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT