.png)
В опубликованном в 2011 году Gartner «магическом квадранте» рынка виртуализации всего два сегмента (вместо обычных четырех) — лидеры и нишевые игроки. К первым, как нетрудно догадаться, относятся VMware, Citrix и Microsoft, ко вторым, помимо Oracle и RedHat, — компания Parallels. Не столь известная на корпоративном рынке, продукция Parallels пользуется признанием у провайдеров. Так, например, 8 из 20 крупнейших массовых хостеров из соответствующего квадранта Gartner, в числе которых Rackspace, GoGrid и Hosting.com, внедрили у себя решения Parallels. Однако, как и в случае с VMware, Parallels — это не только виртуализация. Компания предлагает целую линейку продуктов для автоматизации деятельности провайдеров, у которых имеется от одного до десятков тысяч серверов. А недавно появившееся решение Parallels Automation for Cloud Infrastructure позволяет им предлагать масштабируемые сервисы IaaS по типу Amazon Elastic Computе Cloud. О решениях Parallels для автоматизации предоставления и биллинга сервисов и о новом продукте PACI в интервью нашему журналу рассказывает Станислав Протасов, сооснователь и глава разработки Parallels.
Журнал сетевых решений/LAN: Parallels утверждает, что 75% его бизнеса связано с автоматизацией. Что, собственно, автоматизирует ПО Parallels?
Станислав Протасов: Мы выпускаем программное обеспечение для сервиспровайдеров, автоматизируем хостинг и облачные вычисления. Обычно провайдерам требуется решить две основные задачи — во-первых, как автоматически создать облачный сервис и предоставить возможность им пользоваться (provisioning), во-вторых, как взимать деньги за его оказание (billing). Обе эти задачи решает платформа автоматизации Parallels Automation. Предоставление сервиса может быть как очень простым (например, открытие почтового ящика), так и чрезвычайно сложным (бухгалтерские проводки в режиме онлайн), в последнем случае создается множество объектов.
Биллинг — наиболее важная часть нашей платформы. Создав сервис, необходимо обеспечить взимание платы за его использование. При этом желательно предоставить заказчику разные возможности и схемы оплаты — с использованием банковской карты, PayPal, «Яндекс.Деньги», по предоплате, в кредит и другие варианты. Платформа позволяет описать предоставляемый сервис (в частности, выделяемые внутренние ресурсы — вычислительные мощности, объем дискового пространства и т. д.), а также правила его предоставления. В зависимости от размера бизнеса провайдера выбирается Parallels Plesk Panel, Parallels Plesk Automation или Parallels Automation — от малого к большому. Крупным провайдерам интересна многомодульная, с большими техническими возможностями по интеграции платформа Parallels Automation.
LAN: Возможности названной платформы «закрывают» все потребности сервис-провайдеров при предоставлении услуг?
Протасов: Большое число провайдеров пользуется исключительно платформой, и это дает основание утверждать, что им вполне достаточно имеющегося функционала. Однако многие игроки на этом рынке появились не вчера. Так, у телекоммуникационных операторов, которые становятся мощными игроками на облачном рынке, уже есть собственные внутренние системы для биллинга, где они ведут всю свою клиентскую базу. Вместе с тем им интересны возможности предоставления дополнительных сервисов с помощью облачных вычислений, что в конечном итоге приводит к увеличению ARPU. Для успешной продажи облачных сервисов необходимо, чтобы наше решение было интегрировано с существующими системами. Выставление нескольких счетов из разных систем усложняет контроль за сбором средств и вызывает у клиента негативные эмоции.
LAN: Какие потребности провайдеров призвано удовлетворить решение Parallels Plesk Automation?
Протасов: Все зависит от услуг сервиспровайдера и, как правило, его размера. Как я уже сказал, Parallels Automation позволяет создавать любые сервисы IaaS, SaaS, PaaS и предназначена для крупных провайдеров, у которых установлены тысячи и десятки тысяч серверов. Plesk Panel изначально разрабатывалась как контрольная панель для управления сервисами в пределах одного физического сервера, где планируется создать какоето количество Web-сайтов, доменов, почтовых ящиков. Иначе говоря, пользователи таких средств автоматизации — это небольшие игроки, имеющие всего несколько десятков серверов. Parallels Plesk Automation занимает промежуточное положение между Parallels Plesk и Parallels Automation. Когда у вас есть три сервера, можно зайти в три контрольные панели Plesk, чтобы произвести одинаковые действия. Да, это не очень удобно, но и не слишком накладно. Но если у вас 20 серверов и на каждый надо потратить по 15 минут, то это уже 5 часов работы. По сути, Plesk Automation — это решение для управления и биллинга сразу нескольких серверов.
LAN: Для автоматизации сервисов необходимо автоматизировать и предоставление ресурсов. На ваш взгляд, каковы перспективы интеграции ваших решений с системами управления инфраструктурой ЦОД?
Протасов: Это очень сложный вопрос.
Системы Data Center Infrastructure Management (DCIM) ведут свое происхождение из корпоративного мира: те, кто их продвигает, ориентированы на корпоративных клиентов. Несмотря на то что коммерческие (провайдерские) и частные (корпоративные) ЦОД имеют немало общего, на практике многие требования существенно различаются. Например, если в компании имеется сервер Exchange, то процесс установки заплат может занимать не один месяц. И дело не в нерадивости администраторов: за малейший сбой в функционировании сервера их ждут серьезные санкции. При этом они рассматривают компанию как дружелюбную среду и вопросы безопасности решают «по периметру». Клиенты сервис-провайдеров, как правило, небольшие компании с численностью 10–50 человек. С точки зрения безопасности их не защищают корпоративные администраторы, и вопрос своевременного закрытия уязвимостей провайдером более важен. А в случае неудачи тут же выполняется откат назад. И таких мелких нюансов множество.
Соответственно, требования к ПО для управления ЦОД у этих двух категорий различаются. Многие игроки DCIM из корпоративного сегмента просто не видны на нашем рынке: мы работаем с публичными облаками, конечные пользователи которых — небольшие и средние компании. С проникновением облачных вычислений буквально во все области ИТ эта разница нивелируется, хотя и медленно. Со временем потребность в интеграции с DCIM, несомненно, возникнет, но пока подобные решения имеются только у очень крупных провайдеров, например у телекоммуникационных операторов. В настоящее время мы ведем переговоры на эту тему с рядом крупных вендоров, в частности с HP и Cisco, но ожидать, что Parallels придет на корпоративный рынок, не стоит: если мы на нем и появимся, то как партнеры больших и чаще всего «железных» вендоров в этом сегменте.
Вместе с тем Parallels будет идеальным партнером для тех, кто намеревается выйти на провайдерский рынок. Тот инструментарий, который использует, скажем, Citigroup, не подходит компаниям Host Europe, 1&1, Intuit. Для работы с ними понадобится Parallels. Так получилось, что всю свою историю мы сотрудничаем с сервис-провайдерами. Не сочтите за хвастовство, но лучше нас этот рынок не понимает никто: мы знаем, какие решения за последние десять лет были эффективными, а какие нет и почему.
LAN: В чем заключался смысл разработки Parallels Automation for Cloud Infrastructure и почему в качестве ориентира была выбрана Amazon Elastic Cloud, а, скажем, не Microsoft Azure?
Протасов: Идея PACI, одного из модулей Parallels Automation, настолько проста, что даже удивительно, почему до сих пор никто не реализовал ее в виде открытой платформы. Основная идея Elastic Cloud состоит в том, чтобы любой желающий мог брать из облака ресурсы по мере появления потребностей в них.
Традиционная схема предполагает выделение фиксированных ресурсов, например дисковой емкости, при исчерпании которых клиент получает предупреждение и может сделать, если захочет, дополнительный заказ. В случае персонального Web-сайта такая схема работает превосходно. Однако если вы сами предоставляете какой-то сервис, например для ведения бухгалтерского учета с выделением ограниченной мощности CPU, то такой подход оказывается неэффективным в случае пиковых нагрузок. В частности, при подготовке квартального отчета всеми клиентами одновременно вычислительной мощности может не хватить. Если вы не хозяин инфраструктуры, то очень желательно получать ее ресурсы автоматически.
В этом и состоит идея эластичности: при нехватке вычислительной мощности серверы предоставляются клиенту автоматически, а потом в ежемесячном счете выставляется плата за их использование (замечу: объем выделяемых ресурсов можно ограничить, чтобы счет не превышал определенной суммы). Приложений, где это требуется, огромное количество. Типичный пример — игровые серверы: чем больше игроков будет играть, тем лучше для владельца сервера, но ресурсы для них надо выделять динамически.
Amazon первым реализовал простой, понятный и, я бы сказал, скупой API для работы со своим облаком. Любой программист может очень быстро разобраться в этом интерфейсе, а затем использовать облако Amazon. Поскольку Amazon начал намного раньше, он долгое время оставался безальтернативным поставщиком такой услуги. Наш API похож на тот, который применяет Amazon. Мы сделали это для тех, кто уже работал с Amazon, чтобы их не останавливал барьер новизны. Однако сходство PACI с EC2 заканчивается интерфейсом, технологически это другой продукт.
LAN: Какова масштабируемость PACI?
Протасов: Это хороший вопрос. Конечно, хотелось бы ответить, что масштабируемость не ограниченна. Вместе с тем в тех инсталляциях, где PACI тестировалась, тысяча серверов поддерживается без проблем. К тому моменту, когда у нас появятся клиенты с сотнями тысяч серверов, PACI будет способна поддерживать такие среды. Как с любым процессом совершенствования, предела здесь нет. Мы знаем узкие места нашего решения и работаем над их устранением — рано или поздно это все равно придется делать, так как бизнес наших клиентов — сервис-провайдеров — растет.
LAN: PACI рассчитана на один центр обработки данных или это решение может охватывать распределенную инфраструктуру?
Протасов: Многие владельцы ЦОД задают тот же вопрос о поддержке географически распределенных ЦОД. Однако в действительности у очень немногих операторов есть разделенные ЦОД, которые способны заменить друг друга при аварии. И даже в этом случае реально реплицируются далеко не все данные. Тем не менее мы работаем над поддержкой географически разделенных ЦОД, возможно даже с полной отказоустойчивостью. Когда это будет реализовано, сказать трудно. Задача весьма непростая: в ЦОД размещаются огромные массивы данных, даже простое их перемещение осуществить непросто. Сегодня все еще нельзя сделать так, чтобы при отказе одного из двух ЦОД клиенты не заметили сбоя.
LAN: В PACI поддерживаются и контейнеры, и виртуальные машины. Почему бы не ограничиться чем-то одним?
Протасов: У контейнеров есть огромное преимущество по сравнению с ВМ — высокая плотность: на одном физическом сервере можно разместить на несколько порядков больше контейнеров, чем ВМ. Это особенно важно для сервис-провайдеров. Вместе с тем, если на виртуальную машину клиент может устанавливать все, что хочет (любую ОС, произвольную конфигурацию и т. п.), то контейнеры такой свободы не предоставляют. Контейнерные решения лучше всего подходят для ситуаций, когда все виртуальные экземпляры похожи друг на друга. Однако даже при полной стандартизации у любого провайдера есть клиенты, которые не укладываются в это прокрустово ложе. К тому же провайдеры используют разные технологии. Переубеждать тех, кто привык к ВМ, переходить на контейнеры — весьма глупое занятие. Они ведь используют их не из религиозных убеждений, а потому что их пользователи, мелкий и средний бизнес, требуют именно ВМ.
LAN: Если решение Amazon Elastic Computе Cloud ориентировано на услуги IaaS, то Microsoft Azure — на PaaS. Как вы оцениваете перспективы разных видов облачных сервисов?
Протасов: Действительно, изначально облако Azure было ориентировано на PaaS, однако затем — год или два назад — появилась возможность загружать в него произвольные образы, в том числе Linux. Иначе говоря, Azure можно теперь использовать в качестве инфраструктуры, а не только как платформу. Таким образом, Microsoft следует своим обычным путем: с помощью одной технологии они постепенно хотят «закрыть» все потребности людей в данной области.
В мире сервисы IaaS используются гораздо шире, чем PaaS: первый сегмент по объему на порядок больше, чем второй (30–40 млрд против 1 мрлд в 2012 году, если верить прогнозам аналитиков). Со временем эта пропорция, конечно, может измениться в пользу PaaS: конечные потребители облачных сервисов, будь то компании или частные лица, хотят решать свои задачи, а не получать контейнеры или ВМ. Но при этом надо учитывать следующее. Молодая компания сочтет очень удобной возможность написать приложение в Visual Studio и опубликовать его в Azure. Однако по мере роста предприятия возникают вопросы стоимости: сколько и за что приходится платить Microsoft. На самом деле нужна инфраструктура, а не платформа. Поэтому вряд ли PaaS вытеснит IaaS — скорее, эти два подхода будут объединяться.