Как создать частное облако?

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

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

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

Недостатками частных облаков считаются необходимость самостоятельного развертывания (а это время и деньги), обучения ИТ-специалистов, управления виртуализацией и автоматизацией, ограничения масштабируемости. Самые острые проблемы - это проблемы лицензирования ПО, поиска инструментов для создания облака, достижения экономии за счет масштаба, характерной для публичных облаков, обеспечения совместной работы разнородных продуктов и обновления серверного парка для полноценной автоматизации и управления, быстрое устаревание технологии, отсутствие стандартов облаков.

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

Нужно идентифицировать и приоритезировать рабочие нагрузки, которые потенциально можно перенести в облако. Проще это сделать для нагрузок, которые легко стандартизируются, являются самодостаточными приложениями или поддерживают SOA. Хуже обстоят дела со сложными нагрузками, нагрузками, требующими значительных изменений, как, например, в случае переноса в облачную среду унаследованных систем. Как показали результаты исследований, для использования в частном облаке наиболее предпочтительны нагрузки, связанные с базами данных и приложениями: интеллектуальный анализ данных, анализ текстовых данных и иные типы аналитики, ИБ, хранилища или витрины данных, непрерывность бизнеса и восстановление после сбоев, инфраструктура среды тестирования, архивирование и долгосрочное хранение данных, транзакционные базы данных, отраслевые приложения и приложения ERP.

Непростой процесс внедрения частных облаков предполагает определение задач доставки сервисов с помощью облака, требований к платформе. Может потребоваться стандартизация образов виртуальных машин, автоматизация миграции приложений, оптимизация ресурсов для динамического предоставления услуг. Необходимо учитывать затраты на аппаратное обеспечение, приобретение лицензий на ПО и обновления, администрирование и поддержку систем, поддержку конечных пользователей и предоставление услуг. Расчет ROI также может включать и улучшение показателей бизнеса, снижение рисков. Рекомендуется рассчитать операционные расходы для унаследованной среды ИТ и среды облачных вычислений в течение трех лет, что позволит оценить долгосрочную окупаемость инвестиций.

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

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

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

Олег Коверзнев, менеджер по развитию бизнеса Cisco:

Переход от виртуализированного ЦОД к частному облаку - это комплексная задача, которая в своей основе имеет не технические, а скорее экономические предпосылки. Более четкий контроль за используемыми ресурсами, система внутренних взаиморасчетов, замена рутинных операций управления автоматическими системами контроля и распределения ресурсов ЦОД - наиболее логичные бизнес-задачи, которые могут быть поставлены перед ИТ-поздразделением компании.

Если считать, что этап виртуализации компанией пройден, и 50-70% серверов уже находятся в виртуальной среде, то этап подготовки к частному облаку сводится к созданию в единого каталога сервисов, внедрению Web-портала самообслуживания и, возможно, модернизации общей структуры управления ресурсами в ЦОД , исходя из принципов централизации и автоматизации процессов ввода сервиса в эксплуатацию. Звучит просто, но на деле многим компаний такая задача просто не под силу: нет квалифицированного персонала, в течение многих лет происходило экстенсивное развитие ЦОД. Как следствие - "зоопарк" аппаратных платформ и ПО управления.

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

Единого рецепта не существует, и каждый заказчик может найти для себя выгоды в разных подходах. В компании Cisco стараются исходить из потребностей и специфики клиента, расширяя набор стандартизованных архитектур за счет сотрудничества с широким спектром производителей программного и аппаратного обеспечения, предлагающих решения для организации частных облаков – EMC, NetApp, IBM, HDS, Vmware, Citrix, Parallels, BMC и др.

Валерий Корниенко, руководитель направления развития сервисных услуг, IBM в России и СНГ:

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

Выбор оптимальной программной и аппаратной платформы для этой цели зависит от решаемых заказчиком задач. Наиболее простой платформой являются серверы стандартной архитектуры, на которых реализуются виртуальные машины. Но ничто не мешает заказчику развернуть частное облако на основе технологий UNIX, поскольку сейчас технологии виртуализации в UNIX имеют высокий уровень развития, особенно на платформе IBM POWER.

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

Если инфраструктура уже загружена на 80-90%, то смысла строить частное облако нет. Если существует проблема пиковых нагрузок, то имеет смысл думать о возможности аренды мощностей у внешнего провайдера. Подразумевается, что при этом решены вопросы безопасности, конфиденциальности и т.д. Вторая основная проблема перехода заключается в ответе на вопрос "как", и мы опять возвращаемся к стандартизации и автоматизации предоставления услуг. Есть ли возможность реализовать ту или иную систему обслуживания конечных пользователей? Либо это уже реализовано у заказчика. В зависимости от того, как это реализовано, оценивается сложность перехода к частному облаку.

Все платформы IBM поддерживают возможность виртуализации. У IBM есть семейство программных продуктов Tivoli, обеспечивающих стандартизацию и автоматизацию предоставления услуг: Tivoli Storage Automation Manager, Tivoli Provisioning Manager и др. Это полный набор средств организации инфраструктуры частного облака, "конструктор", из которого облако можно собирать и достраивать.

Александр Светлаков, менеджер по развитию бизнеса HP BladeSystem:

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

Компания HP предложила в 2008 году унифицированную модель управления серверными нагрузками в ЦОД на основе концепции логических серверов, которые могут быть как физическими , так и виртуальными. Для этого потребовалось придать физическому серверу свойства виртуальной машины: возможность быстрого переноса нагрузки на другой сервер без перекоммутации кабелей и согласования с администраторами сетей передачи данных. Эта задача была решена с помощью технологии виртуализации сетевых соединений HP Virtual Connect для модульных серверов (blade).

Таким образом, уже с 2008 года HP предлагает заказчикам все программные и аппаратные компоненты для построения облачной среды. Наиболее удобным является поставка комплексов HP BladeSystem Matrix, включающих серверы, системы хранения данных, сетевые устройства, управляющее ПО, сервис инсталляции и запуска.

HP BladeSystem Matrix обладает всеми необходимыми свойствами платформы для частного облака:

• - консолидированные пулы ресурсов (серверов, систем хранения данных, сетей LAN и SAN);
• - каталог услуг (протестированные шаблоны для разнообразных приложений);
• - портал самообслуживания (запросы на развертывание инфраструктур бизнес-приложений);
• - автоматическое развертывание инфраструктур;
• - постоянный контроль и оптимизация использования ресурсов.

Для построения полного решения частного облака остается добавить уровень развертывания и управления приложениями. Сегодня возможны следующие варианты:

• - использование ПО HP Cloud Service Automation;
• - интеграция с продуктами Microsoft System Center;
• - применение ПО VMware vCloud Director.

Все варианты внедрения могут быть реализованы с помощью консультантов HP или силами технических специалистов заказчика с использованием «дорожных карт» HP Cloud Foundation.

Антон Жбанков, старший консультант по технологиям, ЕМС Россия и СНГ:

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

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

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

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

Владимир Бедрак, архитектор комплексных решений компании «Астерос»:

При создании облака на базе ЦОД в первую очередь необходимо задуматься о том, какие конкретно ИТ-сервисы будут предоставляться и для каких клиентов.

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

Большая часть рабочих нагрузок для функционирования в облаке требует платформы X86. Именно поэтому его основой являются высокая степень виртуализации стандартной архитектуры и разделяемое хранение данных.

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

Большое внимание необходимо уделить хост-серверам. В последнее время производительность их процессоров растет довольно быстро, поэтому коэффициент консолидации виртуальных машин для будущего облака должен быть не менее 10 на сервер. Объемы оперативной памяти предусматриваются исходя из суммы нагрузок с запасом не менее 50%, порядок уже идет на сотни гигабайт. Высокий коэффициент использования процессора, памяти и управление питанием компонентов – основа энергоэффективного, "зеленого" проекта.

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

Владимир Ливинский, руководитель управления «Вычислительные системы» компании «АйТи»:

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

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

Оптимальной аппаратной платформой для построения облака является набор серверов-лезвий (blade), которые идеально вписываются в идею управляемого экономичного ЦОД, и практически любое ПО виртуализации ведущих вендоров (будь то VMware, Microsoft или Xen). ПО для построения частных облаков от разных вендоров на данный момент имеет схожие характеристики и позволяет отвязать уровень сервисов от уровня аппаратной платформы, повышая при этом управляемость и обеспечивая динамическое выделение ресурсов по требованию.

Вот как ответили на вопрос эксперты корпорации Microsoft:

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

Microsoft предлагает свои решения по четкому делению: Infrastructure as a Service; Platform as a Service и Software as a Service. Причем компания допускает использование каждого уровня как в своем частном облаке, так и во внешнем, публичном. Интеграция и связь между каждым сектором должна обязательно присутствовать, позволяя переводить на нужный облачный сервис именно ту часть существующей инфраструктуры, которая к этому готова.

Рисунок 1. ИТ как услуга на всех уровнях

Когда выведенный в облако компонент становится изолированным от взаимодействия с существующими традиционными решениями, возникает одна из основных проблем. Такой скачкообразный переход не годится для большинства клиентов, и в Microsoft это хорошо понимают. Вот почему компания выбрала путь, когда нет необходимости делать резкие "рывки", но компании могут сами принимать решение, что и где будет находиться. Например, на границе "ЦОД - частное облако" для управления системами в частном облаке используются те же инструменты, которые администраторы применяют для контроля над работой виртуальных машин в виртуальной ферме и для управления другими физическими системами внутри ЦОД и за его пределами. Когда придет время, и появится необходимость подключить публичные ресурсы облаков, это можно будет сделать, не отказываясь от привычных консолей управления System Center, обеспечивая тем самым взаимодействие на уровне "частное - публичное облако".

Нас часто спрашивают: "У меня есть ЦОД с N виртуальными машинами, могу ли я считать свою виртуальную ферму частным облаком, или нет?". Как правило, ответ лежит в самом вопросе. Если вы смотрите на ЦОД как на количество виртуальных машин, как если бы они физическими серверами, то это точно не частное облако. Ключевыми отличиями последнего являются:

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

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

Довольно интересной тенденцией является возрастающее внимание клиентов к переходу от использования только традиционного ЦОД к модели "ЦОД+публичное облако". То есть какая-то часть инфраструктуры, выполняющая определенные задачи, выделяется из ЦОД (поэтому важно понимать на каком этапе развития мы находимся и что уже готово к переходу, а что еще нет) и доверяется на внешнее управление и обслуживание. Например, это касается как хорошо всем знакомых сервисов, обеспечивающих безопасность (например, обновления Microsoft Update, антивирусные сигнатуры Forefront) или предоставляющим возможность работы с электронной почтой и календарями Exchange, так и новых сервисов - "виртуального сервера Windows" или Exchange\Sharepoint Online. Выгоды от переноса этих элементов из частного в публичное облако могут быть приемлемыми для одних компаний и не устраивать другие (из-за нормативных требований и пр.), но, тем не менее, имеющаяся интеграция не должна быть нарушена.

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

В компании Brocade эту проблему прокомментировали так:

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

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

Конфигурирование такой сети сопряжено с рядом сложностей. Например, чтобы соотносить трафик виртуальной машины с физическими компонентами и сетевыми ресурсами, мониторинг должен быть более интеллектуальным. В связи с требованиями SLA приложений принципиальное значение приобретает QoS, распределение полосы пропускания и формирование трафика (traffic shaping).

Характер трафика серверного облака сильно отличается от характера трафика при соединениях "клиент–сервер". В серверных облаках трафик между стойками ("восток-запад") может быть намного больше. Классические сети Ethernet поддерживают только трафик "север-юг", что добавляет задержку в трафик серверного облака, переносимый между стойками, так как ему приходится двигаться вверх и вниз, преодолевая несколько сетевых уровней. Для облака серверов требуется более плоская сеть второго уровня, объединяющая множество стоек, чтобы трафик "восток-запад" передавался эффективно и с малой задержкой.

Поскольку виртуальные машины могут перемещаться, сеть должна "знать", как отображать их на свою сетевую политику. Виртуальным машинам присваиваются постоянные MAC-адреса, связанные с соответствующими сетевыми политиками, как если бы это были физические серверы. Но политика должна следовать за МАС-адресами при их переходе от одного физического порта сети к другому.

Для таких рабочих нагрузок, как трафик сети хранения данных, требуются детерминированные сети без потерь. Для пересылки пакетов без потерь iSCSI опирался на свойства протокола TCP. Fibre Channel Over Ethernet (FCoE) опирается на Ethernet – это значит, коммутаторы Ethernet должны поддерживать расширения Data Center Bridging (DCB) для пересылки пакетов без потерь. Кроме того, они должны обеспечивать подключение к серверу по сети 10 Gigabit Ethernet (GbE) с использованием конвергентных сетевых адаптеров (Converged Network Adapters - CNA). Благодаря CNA клиентский IP-трафик и трафик сети хранения данных используют один и тот же физический канал. Однако пропускную способность и QoS нужно тщательно регулировать, чтобы критически важный трафик хранения данных не испытывал помех. Для многих заказчиков интеграция трафика FCoE с существующими сетями хранения данных Fibre Channel является жизненно необходимой для эффективного по стоимости управления СХД, аварийного восстановления и защиты инвестиций.

Ручная настройка многочисленных коммутаторов и портов с общими параметрами, какая требуется для современной сети, не обеспечивает достаточное масштабирование и гибкость, к тому же обходится слишком дорого. Ввиду добавления виртуальных машин и их логической связи с физической сетью и мобильности, а также ввиду объединения трафика IP и хранения данных в одной и той же сети сетевое управление должно стать более гибким и масштабируемым.

Оптимальной технологией для создания облачной сети, нацеленной на распространение виртуализации на весь ЦОД, улучшение гибкости, сокращение затрат и пр., является так называемая Ethernet-фабрика. Ethernet-фабрика – это система, характеризующаяся такими свойствами, как самоагрегация, самовосстановление, прозрачная внутренняя топология и равнозатратная маршрутизация по многим путям (equal-cost multipath routing) на уровне 2.

В сравнении с классическими Ethernet сетями для IP-трафика Ethernet-фабрики исключают Spanning Tree Protocol (STP) и ручную настройку Inter-Switch Links (ISL) и обеспечивают самоагрегируемые ISL (магистрали) с балансировкой нагрузки и автоматическим аварийным переключением каналов. Они обладают распределенным интеллектом, так что сетевые политики и устройства известны на каждом порту. Когда виртуальные машины перемещаются между сетевыми портами, к трафику приложений последовательно применяются соответствующие конфигурации портов и политики. Трафик в Ethernet-фабриках не ограничивается потоками "север-юг", которые движутся вверх и вниз по уровням сети. Вместо этого, сети Ethernet имеют плоскую структуру и эффективно распространяются на несколько серверных стоек, уменьшая время ожидания и исключая узкие места в магистралях ISL.

Для сетей хранения данных последнее десятилетие стандартом был Fibre Channel. Ethernet-фабрики переносят технологии классических SAN на технологию FcoE, а также на сети iSCSI. Для обеспечения мобильности виртуальным машинам нужно подключение к сетевым системам хранения данных, и SAN является наиболее экономически эффективным решением независимо от используемого транспорта – Fibre Channel или Ethernet.

Если обобщить скзанное, то Ethernet-фабрика отвечает главным требованиям, предъявляемым сейчас к облачно-оптимизированной сети в ЦОД, это:

• - Плоская структура. Ethernet-фабрика самоагрегируема, что позволяет получить более "плоскую" сеть.
• - Интеллектуальность. Коммутаторы фабрики "знают" друг друга, и им известны все подключенные устройства.
• - Масштабируемость. Для обеспечения высокой производительности и надежности доступны все пути.
• - Эффективность. Трафик автоматически перемещается по кратчайшему пути.
• - Простота. Фабрика управляется как единый логический объект.

С появлением технологии Brocade Virtual Cluster Switching (VCS) классический Ethernet трансформировался в Ethernet-фабрику. Фабрика делает сеть более плоской, объединяя уровень агрегации и доступа, после чего она соединяется с маршрутизаторами ядра, в качестве которых могут выступать Brocade MLX или маршрутизаторы других вендоров. Трафик сети хранения данных сможет покидать Ethernet-фабрику и маршрутизироваться в классический FC-SAN, построенный на коммутаторах и магистральных решениях Brocade.

С технологией VCS Brocade стала первым вендором, выпустившим на рынок Ethernet-фабрику, которая готова к развертыванию в облачных ЦОД.

Следующий комментарий представили специалисты компании StarWind Software:

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

• - Простой при поломке оборудования.
• - Отсутствие физического места под новые серверы.
• - Отсутствие достаточной мощности электропитания.
• - Охлаждение серверов.

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

А теперь представьте, что буквально в течение месяца можно сделать из всех ваших серверов единое облако, в котором все приложения будут работать без простоев, перемещаясь между серверами в зависимости от их текущей нагрузки и работоспособности их аппаратной части. А если какой-либо из серверов вашего облака «упадет», другой тут же восстановит все приложения на любом сервере, где есть для него свободные ресурсы. Вы скажете: "Какие же ресурсы, если у меня каждый сервер полностью загружен!"

Но на самом деле любой невиртуализированный сервер работает всего лишь на 15-20% своей мощности. Что-то простаивает в любом случае. Где-то "гуляет" процессорное время, где-то диски покрываются пылью, а где-то вообще потерялся всеми забытый принт-сервер, к которому уже год не подключались.

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

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

Если говорить кратко, есть два типа СХД: оптоволоконные (FC) и Ethernet (iSCSI). iSCSI, в свою очередь, бывают аппаратные и программные. FC СХД предоставляют отличную скорость передачи данных, но они крайне дороги и проблематичны в масштабировании. СХД iSCSI до недавнего времени вяло конкурировали с высокой скоростью оптики, но появление в продаже 10-гигабитных сетевых адаптеров значительно перевесило чашу весов в сторону технологии iSCSI для организации хранилищ.

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

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

Например, StarWind iSCSI SAN предоставляет простое и надежное решение для СХД, которое позволяет не только легко и гибко управлять ресурсами, но и значительно экономит средства и на этапе приобретения всех необходимых составляющих для виртуализации хранилища, и в дальнейшем – на этапе масштабирования сети, если оно потребуется. Ценовая политика StarWind делает это решение доступным даже для небольших компаний.

Серьезным плюсом таких СХД решений, как StarWind iSCSI SAN, является обеспечение высокой доступности, или High Availability (HA), что позволяет не беспокоиться за непрерывность бизнес-процесса. В случае выхода из строя одного из узлов хранилища, резервный перехватывает работу приложений, а это - одно из непременных условий успешной виртуализации и приведения ресурсов к «облачному» виду.

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

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

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

Алексей Белкин, заместитель директора по работе с клиентами в РФ и СНГ компании Parallels

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

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

В этом и кроется главная сложность миграции в облака. Когда у каждой компании свой набор приложений – самые большие вопросы вызывает не виртуализация как таковая, а автоматизация всех ИТ процессов. Автоматизировать нужно так называемый "order flow", то есть цепочку "заказ услуги/ресурса => доставка и развертывание услуги/ресурса => учет использования услуги/ресурса => отказ от использования услуги/ресурса и в некоторых случаях изменение параметров услуги/ресурса".

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

Это проще всего показать на примере. Недавно одна крупная российская компания с тысячами офисов по всей России задумалась о переходе на внутреннее облако. Главным драйвером является уменьшение расходов на поддержание электронной почты. Действительно в компании десятки независимых кластеров Microsoft Exchange разбросанных по множеству городов. Как результат, стоимость ежегодного обслуживания всей этой инфраструктуры выливается в огромные деньги.

Первым предложением было свести все почтовые серверы в центральный ЦОД компании с использованием известной платформы виртуализации. Это позволило бы серьезно сэкономить на серверах и их обслуживании, а также решить проблему с персоналом на местах. Но является ли предложенное решение частным облаком? Нет, потому что полная автоматизация отсутствует. Например, количество самих кластеров осталось прежним. Просто теперь они установлены не на физических серверах, а на виртуальных. ИТ-служба вручную создает, изменяет и удаляет почтовые ящики для сотрудников, тратя на это колоссальные ресурсы, учета потребления ресурсов фактически нет.

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

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

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

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

Читайте в февральском номере "Журнала сетевых решений/LAN" обзор "От ЦОД к частному облаку".

Материал подготовил Сергей Орлов — ведущий редактор «Журнала сетевых решений/LAN».