Автор: Пол Роберс (Paul Robers)
На нескольких последних местах работы я имел дело с сервис-провайдерами (поставщиками услуг/ услуг связи/ управляемых услуг) от Исландии до Токио, и все они знают, что безоговорочный лидер («800-фунтовая горилла») – публичное облако – идет по их душу. Какое-то время все они пытались «притвориться мертвыми», но «горилле» все равно и она продолжает бежать в их направлении. Во время всех моих поездок я не сомневался в одном: сервис-провайдеры должны признать, что что-то необходимо кардинально поменять. Как они могут прийти к этому?
Автор фото: Райан Поплин (Ryan Poplin)
Часть моей работы сегодня заключается в посещении клиентов с целью рассказать им, что такое платформа OpenStack, каковы ее возможности, а также могут ли они интегрировать ее со своей инфраструктурой. Ясно одно: чтобы ввязаться в борьбу с вендорами публичных облаков, сервис-провайдеру нужно пересмотреть и доработать свои предложения облачных сервисов, переместив акцент на программно-определяемые технологии и автоматизацию.
Если посмотреть на экосистему публичного облака, то мы увидим, что одним из самых серьезных конкурентных преимуществ платформы являются возможности по автоматизации. К сожалению, многие сервис-провайдеры сегодня используют старую аппаратную и программную инфраструктуру. Я недавно встречался с несколькими сервис-провайдерами, работающими на устаревшей инфраструктуре, которые, как это ни прискорбно, верят в то, что в основе автоматизации лежит скорость, с которой их инженеры способны вращаться в своих креслах. Чтобы выстоять в конкуренции с крупными публичными облаками на сегодняшнем рынке, сервис-провайдеры изучают такие инфраструктуры, как OpenStack, чтобы вновь обрести должную архитектурную основу.
Время от времени я сталкивался с весьма искушенными сервис-провайдерами, которые построили собственные облака на базе OpenStack. Разговор с ними был примерно следующим:
Я: Здорово, что вы работаете на платформе OpenStack. Как с ней обстоят дела?
Они: Это кошмар! Мы потратили недели на то, чтобы выяснить, как все настроить, а нашим инженерам приходится искать ответы через чат IRC и на форумах!
Я: Ого!
Я полагаю, что многие из вас являются владельцем или арендатором своего дома, который требует основного ухода и текущего ремонта. Я уверен, что большинство из вас не являются инженерами-механиками или конструкторами и не имеют представления о том, как в вашем доме все собрано и работает. Этого от нас и не требуется.
Что касается OpenStack, то тут можно провести аналогию с домом. В основе OpenStack лежит множество комплексных проектов на базе открытого исходного кода, которые связаны через сложные API, с которыми воюют даже самые опытные инженеры по технической поддержке инфраструктуры. С финансовой точки зрения выбор данного пути на начальном этапе, вероятно, серьезно скажется на доходах из-за недостигнутых бизнес-целей и срыва сроков. С подходом «сделай сам» множество людей начинают работать с OpenStack и, как правило, терпят неудачу, что оставляет очень неприятное «послевкусие».
Основная бизнес-цель любого сервис-провайдера – помочь спроектировать и обеспечить надежный хостинг приложений заказчика. Ключ к успеху при работе с OpenStack заключается в привлечении вендора, который собрал все необходимые фрагменты кода и предоставит сервис-провайдеру поддержку на уровне предприятия, необходимую ему для ведения бизнеса. Пожалуйста, доверьте техподдержку и упаковку OpenStack проверенному вендору.
Сегодня OpenStack предоставляет основу, с помощью которой клиенты могут упростить инфраструктуры, построенные на разнородных технологиях, путем абстракции и объединения различных программных интерфейсов в одну общую инфраструктуру или один API. Самое главное при этом – повышение эффективности работы центра обработки данных (ЦОД).
С точки зрения сети на данный момент OpenStack предоставляет способы интеграции с такими известными устройствами, как F5 Big-IP, Cisco Nexus, Citrix Netscaler и коммутаторы Arista (ожидается интеграция с еще большим количеством устройств). Что касается хранения, то все – от EMC, NetApp, Coraid и до Nexenta – интегрированы с OpenStack . Относительно гипервизоров вы можете выбрать из таких вариантов, как VMWare, KVM, Xen и HyperV. Сервис-провайдер может использовать в ЦОД подход, полностью не зависящий от инфраструктуры, и позволить OpenStack решать все сложные задачи.
Согласно опросу пользователей на саммите OpenStack в Атланте, бизнес-стимулом №1 для использования OpenStack является возможность избежать привязки к платформе одного вендора. Сервис-провайдеры полагаются на работу с партнерами по производству оборудования и программного обеспечения (ПО), которые не показывают друг на друга пальцем при решении неотложных задач. Сервис-провайдерам также необходимо иметь возможность устанавливать прочные стратегические взаимоотношения, которые позволят им приводить в действие планы развития продуктов того или иного вендора. Если такие взаимоотношения невозможны, сервис-провайдеру чрезвычайно сложно добиться успеха. OpenStack предоставляет сервис-провайдерам гибкость, которая позволит им в любое время освободиться от вендоров и решить, какое сочетание оборудования и ПО будет работать наилучшим для них и их клиентов образом.
OpenStack включает примерно дюжину проектов, но за пределами ядра некоторые из проектов могут представлять больший интерес для сервис-провайдеров, чем другие. Например:
В прошлом я работал в компании Carpathia Hosting, предлагающей облачные сервисы для предприятий. Примерно в 2009 году я работал на стартап, который предоставлял решения для управления жизненным циклом VM и возможности, схожие с теми, которые предлагает проект OpenStack Heat. По сути, мне нужен был способ для описания моего ЦОД посредством некоего концептуального проекта (блюпринта) или кода, который я мог бы сохранить. Затем я хотел иметь оперативную возможность программно инстанцировать новые блоки ЦОД из этого блюпринта. Иными словами, данный стартап предоставлял инструмент, который позволял мне построить Класс ЦОД, после чего я мог инстанцировать новые Объекты. Очень круто! Heat работает точно так же. Это способ оркестровки вашей среды OpenStack при помощи шаблонов, совместимых с сервисом Cloudformation компании AWS. Я очень рекомендую использовать шаблон Heat при каждом развертывании OpenStack для достижения высокого уровня автоматизации. Вы можете найти хорошее руководство по Heat здесь.
Всем сервис-провайдерам необходима возможность определения количества потребляемых ресурсов и периода их потребления. Как упоминалось выше, если вы используете среду, которая не зависит от оборудования, а также несовместимые типы сетей и хранилищ данных, вам необходим единый, унифицированный метод отслеживания используемых ресурсов для упрощения мониторинга и управления. Ceilometer – это проект OpenStack, используемый сервис-провайдерами для предоставления данных об измерениях, которые затем могут быть интегрированы в биллинговую систему. Более подробную информацию можно найти в документации.
Многие сервис-провайдеры используют разные (зачастую сложные и вызывающие головную боль) способы автоматизации сборок своих «чистых» серверов, но в OpenStack сейчас вынашивается проект Ironic, который даст им такую возможность при помощи единого API. Некоторые компании, например Rackspace, заявили о намерениях представить свою собственную версию Ironic под названием OnMetal. Ценность данного проекта больше, чем просто единый API; сервис-провайдеры смогут воспользоваться преимуществами всех возможностей OpenStack, включая измерения, оркестровку, блочное хранилище данных и др., на «чистых» серверах.
Ironic возник из проекта Nova Bare Metal, который затем был свернут. При этом Ironic все еще находится на инкубационном этапе, команда официально считает его «бета-устойчивым» для релиза Icehouse и все еще работает над написанием пользовательской документации и активно исправляет баги. Цель – сделать Ironic доступным в релизе OpenStack Juno, но эта цель может быть расширена. Что касается зрелости, это проект, за которым нужно следить и начать рассматривать внутри лаборатории, но это определенно не проект промышленного уровня. В общем, лично я полон энтузиазма относительно данного проекта и того, как он повлияет на сервис-провайдеров.
OpenStack быстро развивается и будет продолжать это делать. Как сообщество OpenStack, так и вендоры, являющиеся игроками в данном сегменте, работают над тем, чтобы клиентам было проще использовать все ключевые возможности, но все еще имеются пробелы.
Одна из наиболее существенных проблем – поиск эталонных архитектур, соответствующих вашему сценарию использования. Если вы посетите любой Саммит, то станете участником фантастических встреч, но в сухом остатке будет вопрос: «Какую архитектуру мне выбрать?»
Вендоры вносят большое количество кода, пытаясь сделать так, чтобы OpenStack работала с их решениями, но, к сожалению, золотой стандарт, который могли бы использовать сервис-провайдеры, как кажется, отсутствует. На данный момент наиболее распространенные архитектуры, похоже, применяют Ceph для хранения данных, KVM в качестве гипервизора/вычислительного узла, в то время как стандартный вариант сети не существует.
Большинство сервисов в рамках OpenStack на сегодня могут быть защищены посредством HA. Обратите внимание на то, что я использовал слово «большинство». У многих сервис-провайдеров сегодня есть клиенты, применяющие старые или «ленивые» приложения, для обеспечения HA которых требуется основополагающая инфраструктура. Платформа OpenStack на данный момент не предоставляет готовый метод для обеспечения HA всей инфраструктуры; это и не входило в цели ее проектирования. Если быть более лаконичным, OpenStack сегодня не обеспечивает HA для работающих вычислительных узлов Nova: если сами вычислительные узлы выйдут из строя, то их VM автоматически не переключатся на другие узлы. OpenStack использует тот же подход, что и Netflix, полагаясь на то, что разработчики встроят HA в свои приложения. Приложение, действительно работающее на облаке, должно уметь выдерживать любой отказ инфраструктуры.
Прелесть технологий заключается в том, что все проблемы можно решить. Если клиент требует HA, то он может использовать другой гипервизор, который по умолчанию обеспечивает HA, например VMWare, поддерживающий такие классные функциональные возможности, как DRS. Клиенты, которые хотят продолжить работать с KVM, могут воспользоваться, к примеру, Nagios или Zabbix для мониторинга работы данных устройств и даже для автоматического перезапуска сервисов.
Более подробно данный вопрос рассмотрен в блоге моего коллеги Дмитрия Новаковского о недостающих функциональных возможностях в OpenStack.
Кому нужен биллинг? Шучу. Как говорилось выше, сегодня OpenStack представляет проект Ceilometer, который осуществляет мониторинг используемых ресурсов. Одной из имеющихся сложностей является то, что многие сервис-провайдеры используют собственные биллинговые системы и зачастую это абсолютно индивидуальные решения. По всей вероятности, большое сообщество не будет рисковать и создавать какую-то официальную биллинговую систему, так что клиентам лучше всего сотрудничать с вендором, который желает интегрироваться с их существующими системами учета.
Сервис-провайдеры работают в одной из наиболее сложных вертикалей из-за большой конкуренции. Время от времени происходят крупные технологические сдвиги, позволяющие бизнесу стать более динамичным и эффективным. OpenStack представляется наилучшей волной, которую необходимо оседлать в будущем.
Подводя итог, можно выделить несколько ключевых принципов, на которых необходимо сосредоточиться сервис-провайдеру.
1.Избегайте привязки к вендору.
2.Активно применяйте автоматизацию и оркестровку.
3.Не пытайтесь развернуть платформу сами, это большая головная боль, в результате которой вы получите FrankenStack.
4.Сотрудничайте с вендором, беспристрастным к оборудованию и ПО, который поможет вам создать решение, отвечающее вашим потребностям.
5.Дерзайте и развертывайте OpenStack!
Оригинал статьи на английском языке.
На нескольких последних местах работы я имел дело с сервис-провайдерами (поставщиками услуг/ услуг связи/ управляемых услуг) от Исландии до Токио, и все они знают, что безоговорочный лидер («800-фунтовая горилла») – публичное облако – идет по их душу. Какое-то время все они пытались «притвориться мертвыми», но «горилле» все равно и она продолжает бежать в их направлении. Во время всех моих поездок я не сомневался в одном: сервис-провайдеры должны признать, что что-то необходимо кардинально поменять. Как они могут прийти к этому?
Автор фото: Райан Поплин (Ryan Poplin)
Часть моей работы сегодня заключается в посещении клиентов с целью рассказать им, что такое платформа OpenStack, каковы ее возможности, а также могут ли они интегрировать ее со своей инфраструктурой. Ясно одно: чтобы ввязаться в борьбу с вендорами публичных облаков, сервис-провайдеру нужно пересмотреть и доработать свои предложения облачных сервисов, переместив акцент на программно-определяемые технологии и автоматизацию.
Если посмотреть на экосистему публичного облака, то мы увидим, что одним из самых серьезных конкурентных преимуществ платформы являются возможности по автоматизации. К сожалению, многие сервис-провайдеры сегодня используют старую аппаратную и программную инфраструктуру. Я недавно встречался с несколькими сервис-провайдерами, работающими на устаревшей инфраструктуре, которые, как это ни прискорбно, верят в то, что в основе автоматизации лежит скорость, с которой их инженеры способны вращаться в своих креслах. Чтобы выстоять в конкуренции с крупными публичными облаками на сегодняшнем рынке, сервис-провайдеры изучают такие инфраструктуры, как OpenStack, чтобы вновь обрести должную архитектурную основу.
Подход «Сделай сам» при работе с OpenStack
Время от времени я сталкивался с весьма искушенными сервис-провайдерами, которые построили собственные облака на базе OpenStack. Разговор с ними был примерно следующим:
Я: Здорово, что вы работаете на платформе OpenStack. Как с ней обстоят дела?
Они: Это кошмар! Мы потратили недели на то, чтобы выяснить, как все настроить, а нашим инженерам приходится искать ответы через чат IRC и на форумах!
Я: Ого!
Я полагаю, что многие из вас являются владельцем или арендатором своего дома, который требует основного ухода и текущего ремонта. Я уверен, что большинство из вас не являются инженерами-механиками или конструкторами и не имеют представления о том, как в вашем доме все собрано и работает. Этого от нас и не требуется.
Что касается OpenStack, то тут можно провести аналогию с домом. В основе OpenStack лежит множество комплексных проектов на базе открытого исходного кода, которые связаны через сложные API, с которыми воюют даже самые опытные инженеры по технической поддержке инфраструктуры. С финансовой точки зрения выбор данного пути на начальном этапе, вероятно, серьезно скажется на доходах из-за недостигнутых бизнес-целей и срыва сроков. С подходом «сделай сам» множество людей начинают работать с OpenStack и, как правило, терпят неудачу, что оставляет очень неприятное «послевкусие».
Основная бизнес-цель любого сервис-провайдера – помочь спроектировать и обеспечить надежный хостинг приложений заказчика. Ключ к успеху при работе с OpenStack заключается в привлечении вендора, который собрал все необходимые фрагменты кода и предоставит сервис-провайдеру поддержку на уровне предприятия, необходимую ему для ведения бизнеса. Пожалуйста, доверьте техподдержку и упаковку OpenStack проверенному вендору.
Что дает OpenStack
Сегодня OpenStack предоставляет основу, с помощью которой клиенты могут упростить инфраструктуры, построенные на разнородных технологиях, путем абстракции и объединения различных программных интерфейсов в одну общую инфраструктуру или один API. Самое главное при этом – повышение эффективности работы центра обработки данных (ЦОД).
С точки зрения сети на данный момент OpenStack предоставляет способы интеграции с такими известными устройствами, как F5 Big-IP, Cisco Nexus, Citrix Netscaler и коммутаторы Arista (ожидается интеграция с еще большим количеством устройств). Что касается хранения, то все – от EMC, NetApp, Coraid и до Nexenta – интегрированы с OpenStack . Относительно гипервизоров вы можете выбрать из таких вариантов, как VMWare, KVM, Xen и HyperV. Сервис-провайдер может использовать в ЦОД подход, полностью не зависящий от инфраструктуры, и позволить OpenStack решать все сложные задачи.
Согласно опросу пользователей на саммите OpenStack в Атланте, бизнес-стимулом №1 для использования OpenStack является возможность избежать привязки к платформе одного вендора. Сервис-провайдеры полагаются на работу с партнерами по производству оборудования и программного обеспечения (ПО), которые не показывают друг на друга пальцем при решении неотложных задач. Сервис-провайдерам также необходимо иметь возможность устанавливать прочные стратегические взаимоотношения, которые позволят им приводить в действие планы развития продуктов того или иного вендора. Если такие взаимоотношения невозможны, сервис-провайдеру чрезвычайно сложно добиться успеха. OpenStack предоставляет сервис-провайдерам гибкость, которая позволит им в любое время освободиться от вендоров и решить, какое сочетание оборудования и ПО будет работать наилучшим для них и их клиентов образом.
Интересные проекты для сервис-провайдеров
OpenStack включает примерно дюжину проектов, но за пределами ядра некоторые из проектов могут представлять больший интерес для сервис-провайдеров, чем другие. Например:
Heat
В прошлом я работал в компании Carpathia Hosting, предлагающей облачные сервисы для предприятий. Примерно в 2009 году я работал на стартап, который предоставлял решения для управления жизненным циклом VM и возможности, схожие с теми, которые предлагает проект OpenStack Heat. По сути, мне нужен был способ для описания моего ЦОД посредством некоего концептуального проекта (блюпринта) или кода, который я мог бы сохранить. Затем я хотел иметь оперативную возможность программно инстанцировать новые блоки ЦОД из этого блюпринта. Иными словами, данный стартап предоставлял инструмент, который позволял мне построить Класс ЦОД, после чего я мог инстанцировать новые Объекты. Очень круто! Heat работает точно так же. Это способ оркестровки вашей среды OpenStack при помощи шаблонов, совместимых с сервисом Cloudformation компании AWS. Я очень рекомендую использовать шаблон Heat при каждом развертывании OpenStack для достижения высокого уровня автоматизации. Вы можете найти хорошее руководство по Heat здесь.
Ceilometer
Всем сервис-провайдерам необходима возможность определения количества потребляемых ресурсов и периода их потребления. Как упоминалось выше, если вы используете среду, которая не зависит от оборудования, а также несовместимые типы сетей и хранилищ данных, вам необходим единый, унифицированный метод отслеживания используемых ресурсов для упрощения мониторинга и управления. Ceilometer – это проект OpenStack, используемый сервис-провайдерами для предоставления данных об измерениях, которые затем могут быть интегрированы в биллинговую систему. Более подробную информацию можно найти в документации.
Ironic
Многие сервис-провайдеры используют разные (зачастую сложные и вызывающие головную боль) способы автоматизации сборок своих «чистых» серверов, но в OpenStack сейчас вынашивается проект Ironic, который даст им такую возможность при помощи единого API. Некоторые компании, например Rackspace, заявили о намерениях представить свою собственную версию Ironic под названием OnMetal. Ценность данного проекта больше, чем просто единый API; сервис-провайдеры смогут воспользоваться преимуществами всех возможностей OpenStack, включая измерения, оркестровку, блочное хранилище данных и др., на «чистых» серверах.
Ironic возник из проекта Nova Bare Metal, который затем был свернут. При этом Ironic все еще находится на инкубационном этапе, команда официально считает его «бета-устойчивым» для релиза Icehouse и все еще работает над написанием пользовательской документации и активно исправляет баги. Цель – сделать Ironic доступным в релизе OpenStack Juno, но эта цель может быть расширена. Что касается зрелости, это проект, за которым нужно следить и начать рассматривать внутри лаборатории, но это определенно не проект промышленного уровня. В общем, лично я полон энтузиазма относительно данного проекта и того, как он повлияет на сервис-провайдеров.
Чего не хватает OpenStack?
OpenStack быстро развивается и будет продолжать это делать. Как сообщество OpenStack, так и вендоры, являющиеся игроками в данном сегменте, работают над тем, чтобы клиентам было проще использовать все ключевые возможности, но все еще имеются пробелы.
Эталонные архитектуры
Одна из наиболее существенных проблем – поиск эталонных архитектур, соответствующих вашему сценарию использования. Если вы посетите любой Саммит, то станете участником фантастических встреч, но в сухом остатке будет вопрос: «Какую архитектуру мне выбрать?»
Вендоры вносят большое количество кода, пытаясь сделать так, чтобы OpenStack работала с их решениями, но, к сожалению, золотой стандарт, который могли бы использовать сервис-провайдеры, как кажется, отсутствует. На данный момент наиболее распространенные архитектуры, похоже, применяют Ceph для хранения данных, KVM в качестве гипервизора/вычислительного узла, в то время как стандартный вариант сети не существует.
Высокая доступность (HA)
Большинство сервисов в рамках OpenStack на сегодня могут быть защищены посредством HA. Обратите внимание на то, что я использовал слово «большинство». У многих сервис-провайдеров сегодня есть клиенты, применяющие старые или «ленивые» приложения, для обеспечения HA которых требуется основополагающая инфраструктура. Платформа OpenStack на данный момент не предоставляет готовый метод для обеспечения HA всей инфраструктуры; это и не входило в цели ее проектирования. Если быть более лаконичным, OpenStack сегодня не обеспечивает HA для работающих вычислительных узлов Nova: если сами вычислительные узлы выйдут из строя, то их VM автоматически не переключатся на другие узлы. OpenStack использует тот же подход, что и Netflix, полагаясь на то, что разработчики встроят HA в свои приложения. Приложение, действительно работающее на облаке, должно уметь выдерживать любой отказ инфраструктуры.
Прелесть технологий заключается в том, что все проблемы можно решить. Если клиент требует HA, то он может использовать другой гипервизор, который по умолчанию обеспечивает HA, например VMWare, поддерживающий такие классные функциональные возможности, как DRS. Клиенты, которые хотят продолжить работать с KVM, могут воспользоваться, к примеру, Nagios или Zabbix для мониторинга работы данных устройств и даже для автоматического перезапуска сервисов.
Более подробно данный вопрос рассмотрен в блоге моего коллеги Дмитрия Новаковского о недостающих функциональных возможностях в OpenStack.
Биллинг
Кому нужен биллинг? Шучу. Как говорилось выше, сегодня OpenStack представляет проект Ceilometer, который осуществляет мониторинг используемых ресурсов. Одной из имеющихся сложностей является то, что многие сервис-провайдеры используют собственные биллинговые системы и зачастую это абсолютно индивидуальные решения. По всей вероятности, большое сообщество не будет рисковать и создавать какую-то официальную биллинговую систему, так что клиентам лучше всего сотрудничать с вендором, который желает интегрироваться с их существующими системами учета.
Сервис-провайдеры, сделайте это реальностью!
Сервис-провайдеры работают в одной из наиболее сложных вертикалей из-за большой конкуренции. Время от времени происходят крупные технологические сдвиги, позволяющие бизнесу стать более динамичным и эффективным. OpenStack представляется наилучшей волной, которую необходимо оседлать в будущем.
Подводя итог, можно выделить несколько ключевых принципов, на которых необходимо сосредоточиться сервис-провайдеру.
1.Избегайте привязки к вендору.
2.Активно применяйте автоматизацию и оркестровку.
3.Не пытайтесь развернуть платформу сами, это большая головная боль, в результате которой вы получите FrankenStack.
4.Сотрудничайте с вендором, беспристрастным к оборудованию и ПО, который поможет вам создать решение, отвечающее вашим потребностям.
5.Дерзайте и развертывайте OpenStack!
Оригинал статьи на английском языке.
