Как выбирать облака?

Для облачного решения, как для любой вычислительной системы первый критерий выбора - это производительность. А одним из важных свойств облака является его масштабируемость, эластичность. Это свойство в первую очередь и обеспечивают ключевое экономическое преимущество облака - “платишь за то, что используешь”.

Связана ли масштабируемость с производительностью?

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

Горизонтальное масштабирование достигается наращиванием/уменьшением количества виртуальных серверов. Такое масштабирование возможно, к примеру, для задач, решаемых web-серверами, серверами поиска… Т.е. там, где имеется кластерная инфраструктура, позволяющая распараллеливать нагрузку.

Вертикальное масштабирование подразумевает изменение мощности виртуального сервера - “размеров” виртуальной машины. Для этого в рамках пула физических серверов должны иметься ресурсы для увеличения производительности виртуального сервера - процессоров и памяти.

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

Тут надо отметить, что неважны размеры компании, которая передает свои ИТ-системы в облако. Важны задачи, которые решает заказчик в облаке. У небольших предприятий могут быть приложения, которым нужна высокая скорость обработки данных, а у крупных компаний есть достаточно много приложений, которые не столь требовательны к производительности. Поэтому в данном материале мы стараемся не использовать терминологию “малый, средний и крупный бизнес”. Нам кажется уместнее обсуждать проблему в рамках понятий “недорогие” “массовые” и “дорогие”, “тяжелые” “корпоративные” решения.

Вернемся к производительности.

В общем виде общая производительность облачного решения складывается из производительности вычислительной инфраструктуры и производительности системы хранения данных (СХД).

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

Максимальный “размер” виртуальной машины (ВМ) в облаке и любой другой виртуализированной ИТ-инфраструктуры определяется конфигурацией физического сервера. Большое количество маленьких физических серверов нельзя объединить в одну большую виртуальную машину. И это очень важно для понимания - какие задачи можно решать в облаке.

В тяжелых решениях требуются более мощные виртуальные машины, и физические серверы должны иметь возможности создания таких машин. Но облако может строиться и на недорогих небольших серверах: блейд-серверы, одноюнитовые серверы. Тем - какие физические серверы лежат в основе архитектуры облака - в первую очередь и отличаются облака сервис-провайдеров, ориентированных на корпоративный рынок, от облаков провайдеров, ориентированных на - назовём его так - “массовый” рынок.

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

Если заказчик предъявляет высокие требования к производительности виртуальных машин, то надо смотреть как устроено облако и искать сервис-провайдера с такой архитектурой, которая позволяет выделить ему нужные по производительности виртуальные машины. Т.е. заказчику придется-таки понять - на чем реализовано облако и какие могут быть ограничения даже, если они в явном виде не присутствуют в договоре. Это не значит, что их нет. Заказчик должен понимать, что если ему надо будет увеличивать мощность виртуальной машины по мере роста задачи, то физические серверы должны позволять это сделать.

Перейдем к СХД.

Производительность дисковой систем измеряется в IOPS (Input/Output Per Second) и для корпоративных систем это очень важный параметр, зависящий от как от типов применяемых накопителей, так и архитектуры СХД.

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

Однако, у корпоративного заказчика, как правило, есть спектр задач в области организации взаимодействия СХД и серверными мощностями. Для каких-то операций требуется малое время отклика - это характерно для БД ERP систем, например. Есть задачи по хранению бэкапов тех же БД. Есть те же не столь критичные по времени отклика задачи файлового хранения. Чтобы обеспечить выполнение всего многообразия задач, организуется иерархическое хранение данных и используются различные системы хранения от быстрых и дорогих твердотельных до сравнительно дешевых SATA-дисков. Все это образует экосистему хранения данных. И для ее связи ее с вычислительными мощностями - серверами - организуется сеть хранения данных (SAN) - это отдельный аппаратный комплекс, повышающий стоимость решения. Все эти системы должны быть в облаке, ориентированном на корпоративные задачи.

Т.е., невозможно ограничиваться запросом: “Дайте мне пять процессоров, 20 МБ памяти и 100ГБайт СХД”. На этот вопрос можно получить сто разных ответов с разной ценой и все они будут формально правильные. Но это не значит, что заказчик сможет получить решение своей задачи во всех этих вариантах. И это не значит, что кто-то “заелся”, а кто-то продает “по-честному”. Решения могут быть реализованы по-разному, а ответ на ваш вопрос надо искать детально рассматривая архитектуру облачного решения, отталкиваясь от вашей задачи.

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

Мы рассмотрели, пожалуй, основные вопросы, на которые надо получить ответы, обращаясь к облачному провайдеру.

Есть еще несколько дополнительные факторов, о которых тоже нужно знать заказчику.

Каналы связи:

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

Обратите внимания как провайдер обеспечивает антивирусную защиту и есть ли она по умолчанию в услуге или подключается как дополнительная опция.

В завершение.

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

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

Василий Аникушин, руководитель отдела подготовки коммерческих решений компании “Онланта”.

Материал опубликован 7 марта 2014 года в 4CIO Digest на сайте 4cio.ru.