+66 голосов |
В предыдущих публикациях я постарался рассказать об общепринятой терминологии и основных принципах построения облачной среды, представить свое видение важности использования виртуализации в облачных инфраструктурах. В этой же я хочу описать достаточно легкий, но важный этап в переходе на сервисо-ориентированную модель ИТ — стандартизацию.
Имеются два ключевых момента, ради которых необходимо по максимуму стандартизировать всю инфраструктуру перед миграцией в «облако»:
-
последующая автоматизация. Уровень автоматизации прямо пропоорционально зависит от стандартизации, так как при стандартизованной инфраструктуре автоматизация рабочих процессов упрощается в разы;
-
администрирование. В некоторых ситуациях администраторам все же приходится «спускаться» на инфраструктурный уровень, дабы, к примеру, собрать журналы с ОС или IML в случае сервисного события или просто в целях мониторинга. В стандартизованной инфраструктуре администратор всегда знает, где установлено оборудование или до какой степени обновлена ОС, соответственно, эффективность его работы повышается.
Прежде чем перейти к деталям, предлагаю принять за аксиому: стандартизация инфраструктурных сервисов (DHCP, AD/LDAP, DNS, NTP, развертывание сервера, контроль версий и т.д.) является первым и важнейшим условием для построения облачной среды и добавления в нее любого активного оборудования. Об этом говорится в документации к любому ПО, которое формирует ядро облака. Многие дистрибутивы также включают специальные мастера для проверки соблюдения всех инфраструктурных и аппаратных требований. Такие приложения могут быть очень пригодиться в стандартизации на всех уровнях.
Итак, по порядку:
Стандартизация инфраструктурных сервисов заключается в разработке и реализации единой конфигурации для каждого сервиса. Если, к примеру, у вас есть несколько региональных офисов со своим активным оборудованием и собственными субдоменами в древе AD, то эту практику следует распространить на все региональные офисы. В свою очередь, распознавание имен необходимо для всех компонентов инфраструктуры — как прямое, так и обратное. Если у вас есть NTP-сервер, синхронизируйте через него все компоненты инфраструктуры, а не только бизнес-критичные. Результатом станет минимизация «нюансов» в эксплуатационных процессах, а значит, их можно будет легко автоматизировать.
Стандартизация протоколов подразумевает их унификацию. К примеру, для мониторинга глобально выбран протокол WBEM. В этом случае на всех коммутаторах будет открыт порт 5989, а на всех ОС — установлены агенты. Такой же принцип используется при стандартизации и развертывании серверов. К примеру, установка ОС глобально работает по РХЕ-протоколу. Успешным результатом этого этапа стандартизации будет существенное повышение эффективности автоматизации, так как «портфолио» приложений промежуточного слоя и технологических карт будет уменьшено в разы, а автоматизация, в основе которой и лежат технологические карты, станет более предсказуемой.
Версионная стандартизация необходима для минимизации рисков предоставления и обслуживания сервисов. Задача на этом этапе одна: создание и соблюдение базового уровня по версиям микропрограмм, драйверов и ПО промежуточного слоя, согласно спискам совместимости от производителей. Для удобства ее решения существует множество инструментов для организации репозиториев с прошивками, драйверами и сопутствующими приложениями. С их помощью можно и конфигурировать базовые уровни как таковые, и централизовано выполнять обновление по любым схемам (с тестовой обкаткой на одной системе и пр.)
Последний этап я называю организационной стандартизацией. Его задачей является определение единой системы имен серверов, LUN, конфигураций, резервных копий, а в итоге — и сервисов. Результат организационной стандартизации только один — облегчение жизни администраторам, а, следовательно, и повышение эффективности их работы.
Общий итог: стандартизацию достаточно легко реализовать в любой среде, потому что она не требует финансовых вложений. Главным результатом, помимо повышения эффективности и оптимизации работы компонентов, будет «предсказуемость» работы инфраструктуры и ее сервисов, а значит — снижение рисков.
Kingston повертається у «вищу лігу» серверних NVMe SSD
+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...