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

В работе с клиентами я всегда выделяю два основных момента — цель автоматизации и соответствующие ей средства. Цель раскрывает, якобы, очевидную задачу — что автоматизировать, но здесь в 80% случаев и встречается самое большое количество нюансов. Как правило, продуктивная ИТ-среда на 95% статична и эволюционно создается несколькими поколениями администраторов. Если же, к примеру, инфраструктуру для Exchange необходимо предоставить всего один раз, то ROI автоматизации этого процесса, с учетом CAPEX на закупку ПО частного «облака» и времени его внедрения, будет исчисляться не месяцами, а годами.

Легко понять, что эффективно автоматизировать можно и нужно только повторяющиеся операции: выдачу ресурсов для тестирования и разработки, рутинные задачи администрирования системы (патчинг, обновление, масштабирование, отработка скриптов fail-over, резервирование, восстановление, аудиты на безопасность) и т.п.

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

• отсутствие привязки к вендору. Ранее лишь один оркестратор работал с оборудованием и ПО всех производителей. Сегодня же каждый уважающий себя вендор добавил такую функциональность в свое решение. Поддержка чужих продуктов осуществляется с помощью так называемых коннекторов, которых у оркестратора может насчитываться более 5 тыс. С такими возможностями можно автоматизировать любую задачу по предоставлению и обслуживанию multi-mesh-сервисов со сложной архитектурой и применением ПО нескольких производителей. К примеру, один мой коллега полностью автоматически ревернул сервис, который был размещен на партиции Power сервера IBM с ОС AIX, в связке с виртуальной машиной, в которую была автоматически установлена БД Oracle 11. Сам гипервизор х86-архитектуры был также автоматически развернут на блейд-сервере HP BL460c G7;

• интеграция в существующую архитектуру, т.е. с имеющимися системами мониторинга, резервирования/восстановления данных, deployment-серверами, гипервизорами и т.д. Причем, интеграция должна быть настолько полноценной, чтобы позволять автоматизировать не только реакцию на событие в системе мониторинга, но, при необходимости, и восстановление данных с ленточной библиотеки в другой ЦОД, не говоря уже об отработке workflow для обеспечения отказоустойчивости;

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

Подводя итог всему вышесказанному, я бы сделал следующие выводы:

• автоматизация ИТ отнюдь не реализует концепцию «автоматического ИТ», которое никогда не «падает» и работает без участия ИТ-специалистов. Но она существенно облегчает администраторам жизнь и повышает эффективность ИТ в целом. Я люблю проводить параллель с переносом данных. Лет 10 назад, чтобы записать данные на внешний носитель, приходилось использовать специальное ПО и выполнять довольно сложную процедуру, включающую верификацию данных и т.д. Сейчас — вставили флешку, перетащили папку, унесли. Задача решена в разы проще и быстрее, но в обоих случаях — без человека не обошлось;

• при эффективной автоматизации ИТ можно реально экономить ОРЕХ и быстро окупить САРЕХ на приобретение облачного ПО;

• с использованием комплексного решения с автоматизацией процессов и планированием, обслуживание ИТ превращается из реактивного процесса в проактивный.

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

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

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

• сервер, на котором устанавливается инструмент управления инфраструктурой (Central Management Server, CMS) естественно должен иметь доступ к оборудованию на всех площадках;

• без стандартизации инфраструктуры CMS никогда не обеспечит полноценного и эффективного управления ею. От него у вас будет больше проблем, чем пользы;

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

• SSO — очень эффективная вещь при работе с ИТ-инфраструктурой через CMS;

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

Фактически, на этот этапе вы получите первичный вариант той самой «единой консоли» управления активами ИТ-инфраструктуры, но пока что еще не ИТ-сервиса.

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

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

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

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

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

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

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

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

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

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

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

Лично я, основываясь на практическом опыте построения и внедрения «облаков», пришел к выводу – в «облаке» все должно быть виртуализовано по максимуму. Речь идет не только о гипервизоре, так что обо всем по порядку.

Гипервизор – программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких или даже многих операционных систем на одном и том же хост-компьютере (см. Wikipedia). «Облако» не должно вас ограничивать в выборе гипервизора – сегодня VMWare оправдывает свои деньги, а завтра, скажем, Microsoft выпустит отличный и существенно более дешевый Hyper-V, а послезавтра на первый план выйдет KVM в силу своей открытости. Так что вы всегда должны иметь выбор гипервизора, который актуален на текущий момент по соотношению цена/качество. Это сохранение инвестиций, оптимизация расходов. Тем более, что консоль управления базовой функциональностью гипервизоров все равно одна – соответствующее ПО (vCenter, Mircosoft VMM, KVM Appliance, пр.) просто подключается к «облаку» в роли провайдера ресурсов.

Виртуализация СХД – первый виртуализованный массив в мире появился у компании Hewlett-Packard и назывался HP Enterprise Virtual Array. Сегодня в портфолио каждого производителя СХД имеется не один виртуализованный массив, и все они по-своему хороши.

В чем суть виртуализации СХД:

Все жесткие диски объединяются в так называемые дисковые группы. Вы оперируете емкостью не нескольких дисков, собранных в RAID, а – всей дисковой группы, создавая там логические диски (LUN) уже с виртуальным уровнем RAID (vRAID). Данные на диск записываются в блочном виде и равномерно распределяются между всеми дисками той дисковой группы, в которой создан LUN.

Например, в дисковой группе из 24 дисков емкостью в 3,5 Тб файл, который вы записываете на LUN, делится на 24 равные части. Все операции по обслуживанию, такие как изменение объема LUN или ввод/вывод диска из дисковой группы, обновление прошивок, проводятся легко и в режиме online.

Преимущества такого подхода очевидны:

• более высокая отказоустойчивость. При выходе из строя одного из дисков, массиву нужно восстановить всего лишь 1/24 данных;
• скорость. Над вашими данными работают все 24 шпинделя из дисковой группы;
• абстрагирование от аппаратных ограничений. Роль играет пространство всей дисковой группы, а не отдельного диска. Вы легко можете ввести в группу новый диск и данные перераспределятся уже на 25 дисков без простоя;
• защита данных. Если диск изъят из массива, данные с него не могут быть считаны. Чтобы считать данные, необходимо взять все диски из дисковой группы и расставить их в том же порядке, в котором они стояли в исходном массиве.

Виртуализация ввода/вывода – еще несколько лет назад одно физическое подключение означало один физический сетевой адаптер с одним подключенным в него патчкордом. Сегодня у каждого производителя серверов существует множество технологий виртуализации ввода/вывода из сервера. У компании Hewlett-Packard не один год имеется технология, на которой основана вся концепция Converged Infrastructure, – HP Virtual Connect (VC). Как по мне, задумка достаточно хороша, а реализация наконец-то достигла уровня enterprise. Единственное ограничение, которое я заметил, – технология VC реализована только для blade-серверов и только для шасси с7000, хотя обещают выпуск сетевых адаптеров FlexFabric и для стоечных серверов. Потому вся следующая информация представлена для только для указанного оборудования.

Суть Virtual Connect заключается в следующем (без упоминания про технологию Flex-10):

• каждому серверу назначаются виртуальные МАС- и WWN-адресf, а также серийный номер, которые могут мигрировать от сервера к серверу. При управлении ПО VCEM такая миграция может быть выполнена автоматически по любому «событию» от сервера. С использованием технологии boot-from-SAN я смог эмулировать миграцию физических серверов в шасси, подобную миграции виртуальных машин на хост-сервере (только в режиме offline), так как с «переездом» WWN и МАС, адресов происходит миграция и презентованных LUN дисков (в том числе и с ОС), и настроек сети;
• виртуализация uplink-портов дала возможность абстрагироваться от downlink-портов серверов. Сколько бы у меня серверов ни было в шасси, я могу их подключить в инфраструктуру всего одним uplink-портом;
• в каждый порт сервера, а с использованием HP VC в самом простом сервере HP BL460c их становится восемь, а не два, можно подключить до 1065 VLAN. Я только один раз использовал эту функциональность, когда строил для одного большого украинского банка VDI-инфраструктуру на 5000 пользователей, которые подключались через 920 VLAN-сетей;
• модули VC объединяются в так называемый Virtual Connect Domain, в котором может быть до 4 шасси. А ввиду виртуализованных uplink-портов, серверы из одного шасси могут быть подключены через uplink-порты другого и мигрировать между шасси. Это повышает отказоустойчивость – при выходе из строя целого шасси серверы мигрируют в соседние и подключение происходит через другие uplink-порты.

У компании Cisco виртуализация ввода/вывода реализована на базе технологии Nexus. Принцип работы и цель те же самые – виртуализация WWN- и МАС-адресов серверов с использованием конвергенции со всеми вытекающими. У этой технологии есть свои плюсы:

• виртуализация WWN- и MAC-адресов реализована и для стоечных серверов;
• горизонтальное масштабирование. Для расширения на оборудование с другим шасси или даже в другом шкафу не требуется покупка полноценных коммутаторов, просто докупаются расширительные карты – fabric extender’ы. Получается дешевле;
• каждый сервер, подключенный в фабрику Nexus, имеет не восемь портов, а 116,

но также и минусы:

• для виртуализации ввода/вывода у Cisco необходимо, чтобы серверы были подключены к коммутатору Nexus, с любым другим коммутатором эта технология не работает (опять же, ограничение в выборе оборудования);
• трафик невозможно распределить внутри шасси. Для соединения двух серверов в одном шасси в обязательном порядке требуется внешний коммутатор L2 или L3. В решении НР трафик может коммутироваться внутри шасси;
• отсутствие прямой поддержки от производителя в Украине.

Вывод: благодаря виртуализации для решения эксплуатационных задач с оборудованием нет необходимости ходить в серверную и выполнять операции вручную. Многие задачи сводятся к нажатию кнопок или выполнению команд в CLI консоли управления, причем, нажатие кнопок можно легко автоматизировать. В своем роде это усложнение, так как в стеке появляется новая прослойка, но если эта прослойка работает стабильно, проблем быть не должно и можно наслаждаться преимуществами.

Строим «облако». Часть вводная. Пояснения

Перед очередной тематической публикацией я хотел бы сначала ответить на вопросы, возникшие по поводу вводной части.

1. В этой серии публикаций я ни в коем случае не пытаюсь продать сервисы из своего или чужого «облака». Я пытаюсь рассказать о создании своего собственного «облака» — не важно, публичного или частного, так как принцип построения у них одинаковый. В доказательство тому и существуют гибридные «облака», причем все производители облачных решений включают функциональность гибридного «облака» — Cloud Bursting — в продукты для частных «облаков» даже самого низкого уровня, например, в HP CloudSystem Matrix или Cloupia. Логическая архитектура всех до единого «облаков» имеет следующий вид:

На верхнем уровне находятся портал самообслуживания пользователей с каталогом предоставляемых услуг и портал администратора, в котором последний подтверждает выдачу сервисов, управляет ими, мониторит ресурсы в пулах и доступность самих ресурсов. Это и есть единая консоль, из которой администратор может «провалиться» на инфраструктурный уровень и заглянуть отдельно в консоль ОС каждой системы (RDP, SSH, пр.), в management processor сервера (iLO, MP или HMC, пр.), консоль управления СХД (Command View, LUN Manager или Unisphere, пр.) и т.д. На уровне предоставления находится «технологическое ядро» любого «облака» — оркестратор. Именно в нем инфраструктура преображается в пулы ресурсов и осуществляется вся автоматизация рутинных задач и процессов. На этом уровне находятся и выполняются все скрипты и workflow. Уровень инфраструктуры включает в себя все ресурсы «облака» — серверы, ОС, ПО, СХД, ленточные библиотеки, LAN и SAN. ПО управления всеми этими системами в «облаке» называются «провайдерами ресурсов», потому что позволяют оркестратору на втором уровне предоставлять их в виде пулов.

2. Первая публикация была вводной, чтобы мы могли прийти к одному языку в обсуждении интересующих вопросов. Конкретика будет в следующих публикациях.

3. «Облако» — не панацея от всех проблем в ИТ. «Облако» не отменяет администраторов, но превращает их из системных в сервисных. Ведь «автоматизация» не означает полностью автоматическую работу системы без вмешательства человека, она применяется только для рутинных и повторяющихся задач. К примеру, конфигурация WWN и МАС адресов сервера, привязка к ним зон доступности и VLAN, установка ОС или приложений с middleware, обновлений драйверов и прошивок, патчинг ОС или приложений, создание и презентация LUN с СХД и т.п. в «облаке» происходят автоматически по команде администратора сервиса из своей единой консоли (консоли администратора). Подробнее об автоматизации я расскажу в следующих публикациях.

4. Институтом NIST (бывший ANSI) описаны самые популярные уровни сервисов — IaaS, PaaS и SaaS. Но они не единственные — многие Европейские ВУЗы, внедрившие «облако», для предоставления студентам лабораторных работ используют сервис уровня CaaS (Compute-as-a-Service), где каждому пользователю выдается небольшая инфраструктура с несколькими серверами, виртуальным коммутатором и дисками. Многие для реализации облачной модели владения сервисом и автоматизированного LifeCycle Management интегрировали свою инфраструктуру VDI в частное «облако» и получили сервис DaaS (Desktop-as-a-Service). В Швейцарии есть сервис-провайдер, который продает сервисы уровня DCaaS (DataCenter-as-a-Service), с помощью которого в «облако» по снятому «слепку» переносится полностью вся инфраструктура заказчика. Потому я придерживаюсь мнения, что в облаке должна быть возможность предоставления сервисов XaaS (Everything-as-a-Service).

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

За последний год фактически все крупнейшие мировые производители представили свои облачные решения. Однако при этом не прекращаются обсуждения на тему «Что же такое правильное ‘облако’?».

Так что начать стоит с общего определения. Итак, что же такое инфраструктура, построенная на базе облачных технологий, или, проще говоря, «облако»?

По большому счету, с точки зрения технологий зрения и инструментария облачная среда ничем не отличается от стандартной инфраструктуры. «Облако» — лишь новая методология сопровождения и управления ИТ-инфраструктурой.

Небольшое пояснение вышесказанного на реальном примере. В одной крупной компании, где наша команда строила виртуализованный ЦОД, перестал работать сервис корпоративной почты. Руководитель ИТ-департамента потратил около 20 мин на поиск сотрудника, который должен решить возникшую проблему, так как у администраторов ОС «логи были чистые», у специалистов по эксплуатации оборудования «лампочки были зеленые», в сетевом департаменте «все работало» и т.д. Использование облачного подхода позволило бы избежать ситуации, когда простой вопрос требует несопоставимых временных затрат для выявления слабого звена.

Облачную инфраструктуру обслуживают не системные администратора, а администраторы сервиса. Если рассмотреть базовый сервис ИТ-инфраструктуры, он имеет следующий вид:

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

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

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

Так как «облако» — это не просто технология, которую необходимо лишь инсталлировать, а целое решение, то к нему применяются специфические подходы. Такое решение должно оправдать ожидания, в первую очередь, бизнес-подразделения, поэтому внедрение «облака» — целый процесс, который состоит из ряда предпосылок, требований и методологий. Условно его можно разбить на три основных этапа: PreCloud, Cloud и PostCloud. При этом, смею утверждать, что самый сложный из перечисленных — PreCloud.

PreCloud, в свою очередь, состоит из нескольких подпроцессов, а именно:

• виртуализация;

• стандартизация;

• консолидация;

• автоматизация.

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

В следующих постах попробуем разобраться в каждом из перечисленных этапов и в том, из каких наиболее важных составляющих он состоит.