IaaS-сервис Google, позволяющий запускать виртуальные серверы в облаке, называется Compute Engine. Он доступен из консоли в рамках любого облачного проекта Google (о начале работы с Google Clouds см. “Как хранить данные в облаках Google” www.pcweek.ru/its/article/detail.php?ID=160623).

Запускаем виртуальный сервер в облаке Google

Для создания виртуальной машины выбираем в веб-консоли службу Compute Engine и нажимаем кнопку New Instance. В дополнение к типовым настройкам (название сервера, описание, теги и метаданные) можно выбрать зону, где сервер будет работать физически (Европа или США), мощность сервера (рис. 1), при необходимости — заранее подготовленный системный образ и тип ОС. В отличие от конструкторского сервиса Amazon EC2, где доступны десятки различных ОС, включая Windows, Google предлагает весьма ограниченный набор из трех вариантов Linux (рис. 2). Правда, пользователи могут устанавливать и собственные образы большинства ведущих Linux-дистрибутивов.

Чтобы создать рабочий сервер в поле External IP, надо выбрать вариант со статическим IP-адресом; имеется также возможность перенаправления трафика на указанный IP. По умолчанию сервер будет автоматически перезапускаться в случае непредвиденных сбоев, а в ходе технического обслуживания ЦОДов Google виртуальная машина портируется в другой ЦОД (эти режимы можно отключить). После финального нажатия на кнопку Create стартует процесс создания и запуска виртуального сервера, который проходит заметно быстрее аналогичного процесса Amazon, занимая буквально несколько секунд.

В веб-консоли всегда можно просмотреть список сформированных виртуальных машин, по каждой из них узнать статистику загрузки процессора, сетевой и дисковый трафики (рис. 3). Удобна возможность непосредственного просмотра экрана запущенного Linux-сервера (рис. 4).

Кнопки Reboot, Delete и Clone веб-консоли предназначены соответственно для перезагрузки, удаления или создания новой копии виртуального сервера. Помимо этого пользователям доступны командная строка и развитый интерфейс программного управления виртуальными серверами.

Дополнительные возможности

Раздел веб-консоли Snapshots предназначен для создания запасных копий рабочих дисков; Images позволяет выбрать подходящий дистрибутив для виртуальной машины (практически все варианты сводятся к старым и новым версиям Debian и CentOS); Network определяет рабочую подсеть, Metadata предлагает указать справочные сведения в формате ключ — значение для всех серверов проекта. Раздел Zones информирует о планируемых в ЦОДах Google технических работах (рис. 5), Operations показывает историю действий, выполненных над ресурсами Google Compute Engine в рамках текущего проекта. Quotas демонстрирует потенциально доступные пользователю квоты — к примеру, рядовой клиент может задействовать 24 процессора, 5 Тб дискового пространства и семь статических IP-адресов.

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

Страхуемся от эфемерных данных

По умолчанию виртуальному серверу выдается 10 Гб дискового пространства (в схожем сервисе Amazon EC2 — 30 Гб), однако это пространство считается “эфемерным” и фактически предназначено только для типовой загрузки ОС (Scratch boot disk). После любого сбоя или технического обслуживания физических серверов Google все пользовательские настройки (например, дополнительно установленные приложения и конфигурации) пропадут. Надо отметить, что подобное случается крайне редко: Google поддерживает схему “живой миграции”, когда виртуальный сервер “перемещается” внутри ЦОДа или между оными без прерывания собственной работы.

Amazon EC2 предлагает в качестве страховки по умолчанию подключение “долгосрочного” диска самостоятельного сервиса S3, однако за эту услугу будет взиматься дополнительная плата. Аналогичный вариант Google, только непосредственно интегрированный в Google Compute Engine, называется Persistent Disk. Добавление диска в сервер осуществляется из раздела консоли Disks кнопкой New Disk (рис. 7). В окне настройки можно создать пустой диск (поле Source type) и затем присоединить его к виртуальной машине либо выбрать один из трех вышеупомянутых образов Linux, под который устройство хранения будет размечено в качестве загрузочного. В таком случае на первом этапе создания виртуальной машины в поле Boot source (загрузочный диск) выбирается значение Existing persistent disk, а в поле Source Disk — заранее подготовленный диск (рис. 8).

Объём диска задается в поле Size (10 Гб обойдутся в 0,4 долл. в месяц). Над созданным диском доступна единственная операция удаления (кнопка Delete).

Разбираемся с ценами

Плата за сервисы Google Compute Engine (рис. 9), в отличие от Amazon EC2, взимается с округлением не до часа, а до минут (с момента старта сервера должно пройти не менее десяти минут). Крохотный вариант micro с ОЗУ 600 Мб, одним виртуальным процессором и без локального диска обойдется в 0,019 долл. в час (в Amazon — на один цент дороже). Чуть более мощный сервер с 1,7 Гб ОЗУ и процессором 1,38 ГГц стоит 0,054 долл. в час (в Amazon — 0,06 долл.). Цена часа работы 16-ядерной машины со 104 Гб ОЗУ приблизится к двум долларам. Дополнительно потребуется выплачивать 10—20 центов за гигабайт исходящего трафика (в зависимости от региона) и услуги балансировщика нагрузки: 0,025 долл. в час за пять правил балансировки плюс один цент за каждое дополнительное правило и 0,008 долл. за гигабайт обработанных данных (трафик запросов). Интересно, что за статический и присвоенный машине IP-адрес деньги не взимаются, а за неиспользуемый будет списываться 0,01 долл. в час.

Отмечу, что львиную долю расходов в нагрузочных интенсивных проектах может “съедать” общий трафик — на него подчас приходится заметно больше половины всех затрат (если месячная стоимость эксплуатации составляет несколько тысяч долларов). Ещё одна интересная особенность: Amazon с первых же дней активно списывала с моего счета доллары, невзирая на формальный статус пробного бесплатного режима (некоторые жизненно важные сервисы наподобие статического IP оказались полностью платными), а вот Google, никак особо тестовый период не рекламируя, за точно такие же эксперименты с её IaaS-сервисом не взяла с меня ни цента.

Google Compute Engine против Amazon EC2

В сравнении с аналогичным сервисом Amazon EC2 подход Google выглядит значительно менее гибким и существенно упрощенным — но в то же время более шустрым и простым, а обойдётся он чуть-чуть дешевле. Compute Engine — это скорее классическая IaaS-услуга в формате, доступном у немалого числа интернет-провайдеров, и различие между ним и Amazon EC2 столь велико, что выбор с учетом требований конкретного проекта будет весьма простым и очевидным. Так, если требования к IaaS-услуге просты, марка Linux-дистрибутива не очень принципиальна, а сам проект рассчитан преимущественно на быстрый запуск множества виртуальных экземпляров под конкретную и хорошо отработанную задачу с типовой несложной балансировкой, то Google Compute Engine смотрится лучшим решением. Но как только начинается проектная специфика, когда реализуется многоуровневая архитектура, а в перспективе желательно полностью задействовать потенциал смежных облачных сервисов, лучше остановиться на Amazon EC2 — в частности, потому, что документация Google заметно проигрывает конкуренту. Она не слишком понятна, не очень подробна и при этом перенасыщена техническими деталями.