Облачный хостинг GoGrid

Рэнди Байес (Randy Bias)

Существует множество методов построения облачной инфраструктуры. Amazon Web Services (AWS) использует для этого подход, известный как "сервисная инфраструктура" (service infrastructure), и предлагает для этой цели заказчикам ряд индивидуально настраиваемых, нестандартных и в высшей степени масштабируемых сервисов, позволяющих им перестроить существующую у них инфраструктуру для работы в полностью виртуальной среде. В отличие от AWS, GoGrid1 предоставляет своим клиентам подход, более ориентированный на существующие промышленные стандарты, предлагающий им знакомую среду, напоминающую типичный центр обработки данных, но разворачиваемый в облачной инфраструктуре.

Есть большое количество клиентов, для которых подход GoGrid окажется более "близким по духу", более привычным и комфортным, поскольку в нем находят применение более привычная терминология и более знакомые технологии, например виртуальные локальные сети (VLANs, virtual LANs), сетевые блоки (network block), аппаратные устройства (hardware appliances), такие как балансировщики нагрузки (load balancers), и межсетевые экраны или брандмауэры (firewalls) и сетевые хранилища данных, в том числе — SAN (storage area networks) или NAS (network attached storage). Эти решения определяют используемую нами концепцию "облачного центра обработки данных" (cloudcenter, или "центр обработки данных в облачной среде").

Типы облаков

Инфраструктурные облака (также известные под названием "инфраструктура как сервис", "Infrastructure-as-a-Service" или IaaS) можно строить двумя путями:

1  Подробнее о GoGrid см. http://www.gogrid.com/, http://wiki.gogrid.com/wiki/index.php/Main_Page, http://gogrid.ru/. — Прим. перев.

построением  сервисных  инфраструктур  (service  infrastructures)  или  построением "облачных центров" (cloudcenters).

Оба варианта позволяют представлять клиентам те возможности, которых они вправе ожидать от поставщика услуг IaaS:

± масштабирование по требованию;

± оплата по факту потребления услуги;

± возможность преобразования капитальных расходов (capital expenditures, CapEx) в производственные затраты (operational expenditures, OpEx);

± программные (API) и графические пользовательские (GUI) интерфейсы;

± базовая инфраструктура: пространство для хранения данных, серверы,  сеть, электропитание, охлаждение.

Хотя оба подхода и предоставляют тот же самый базовый набор услуг, они существенно отличаются.

± Сервисные инфраструктуры — этот подход похож на подход, применяемый AWS и широко освещенный в данной книге. Сервисные инфраструктуры в принципе представляют собой индивидуально настраиваемые Web-сервисы в облачной среде. Они могут использоваться как по отдельности, так и в комбинации, с тем, чтобы предоставить клиенту возможность развертывания Web- приложения или выполнения пакетной обработки данных. Например, Amazon предоставляет серверы, пространство для хранения данных, базы данных, обслуживание очередей (queuing)/систем обмена сообщениями (messaging), обработки электронных платежей (payment processing) и многое другое. Каждый отдельный Web-сервис из числа перечисленных представляет собой уникальное и индивидуально настраиваемое решение. Хранилище на базе S3 использует протокол S3 и механизмы организации пространства для хранения данных, специфичные для S3. Сервис обслуживания очередей AWS SQS использует собственный нестандартный патентованный протокол и собственный формат сообщений. Точно так же организован и их сервис управления базами данных SimpleDB. Все эти сервисы компания Amazon разработала так, чтобы обеспечить возможности масштабирования до 50 000 серверов и более, на которых работают тысячи разнообразных программных продуктов. Все предоставляемые сервисы являются общедоступными и могут перенастраиваться так, чтобы клиенты AWS могли применять их в своих собственных целях, в рамках собственных бизнес-моделей.

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

лы, такие как SMB1/CIFS2 и NFS3. Доступ к базам данных обеспечивается посредством стандартного языка SQL и реляционных систем управления базами данных RDBMS). Межсетевые экраны (Firewalls) и балансировщики нагрузки представляют собой специализированные аппаратные устройства, а не распределенное и индивидуально конфигурируемое программное обеспечение.

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

Облачные центры

GoGrid — первый и самый крупный из облачных центов в США, популяризирующий и пропагандирующий этот подход. В качестве примера других компаний, применяющих подход "облачного центра" (cloudcenter), можно  привести FlexiScale4, ElasticHosts5 и AppNexus6. К числу преимуществ данного подхода можно отнести то, что при его использовании вам не потребуется переучиваться, приобретая новые знания и навыки, возможность использования уже существующей инфраструктуры, а также более гибкую облачную среду. Подход компании GoGrid

1 SMB (Server Message Block) — сетевой протокол прикладного уровня для удаленного доступа к файлам, принтерам и другим сетевым ресурсам, а также для межпроцессного взаимодействия. Первая версия протокола была разработана компаниями IBM, Microsoft, Intel и 3Com в 1980-х годах; вторая (SMB 2.0) была создана Microsoft и впервые была введена в Windows Vista. В настоящее время SMB связан, главным образом, с операционными системами Microsoft Windows, где используется для реализации "Сети Microsoft Windows" (Microsoft Windows Network) и "Совместного использования файлов и принтеров" (File and Printer Sharing). Подробнее см. http://en.wikipedia.org/wiki/Server_Message_Block. — Прим. перев.

2 Common Internet File System, см. http://ru.wikipedia.org/wiki/SMB, http://www.samba.org/cifs/. — Прим. перев.

3 Network File System (NFS) — протокол сетевого доступа к файловым системам, первоначально разработанный Sun Microsystems в 1984 году. Основан на протоколе вызова удаленных процедур, позволяет   подключать   (монтировать)   удаленные   файловые   системы   через   сеть.   Подробнее   см.

http://ru.wikipedia.org/wiki/Network_File_System, http://datatracker.ietf.org/wg/nfsv4/charter/, http://wiki.linux-nfs.org/wiki/index.php/Main_Page, http://solarisblog.ru/networks/osnovy-nfs-v-os- solaris. — Прим. перев.

4  FlexiScale — это платформа, работающая по принципу предоставления информационных сервисов как коммунальных услуг (utility computing), созданная компанией XCalibre летом 2007 года, а затем приобретенная компанией Flexiant. Подробнее см.

http://www.flexiant.com/products/flexiscale/, http://www.flexiant.com/. — Прим. перев.

5 ElasticHosts — это международный облачный сервис-провайдер, обладающий двумя центрами обработки   данных   (под   Лондоном   в   Великобритании   и   в   Сан-Антонио,   США).   Подробнее   см.

http://www.elastichosts.com/. — Прим. перев.

6 AppNexus — это компания, которая предлагает аукцион рекламы в реальном времени. Служба AppNexus обслуживает 120 рекламных сетей в 12 странах. См. http://appnexus.com/. — Прим. перев.

предлагает и еще одно преимущество — простоту и удобство интеграции вашего существующего центра обработки данных с внешними облачными средами.

Центры обработки данных в облачных средах

Традиционные центры обработки данных включают в свой состав следующие компоненты:

± защиту периметра сети с помощью аппаратного брандмауэра и сетевой системы обнаружения вторжений (NIDS);

± балансировку нагрузки с помощью аппаратного балансировщика нагрузки;

± сегментацию сети с помощью различных сетевых блоков (network blocks) и виртуальных локальных сетей  (VLAN);

± комбинацию физических аппаратных средств и виртуальных гостевых операционных систем;

± совместный доступ к файлам с использованием NAS;

± блочные устройства хранения (SAN);

± поддержку сервисов центра обработки данных: DNS, DHCP, создание образов серверов (server imaging), управление инвентаризацией (inventory management), управление активами и их мониторинг (asset management and monitoring);

± электропитание, охлаждение, полосу пропускания и резервное копирование для всех перечисленных сервисов;

± круглосуточную непрерывную техническую поддержку и квалифицированный персонал.

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

GoGrid и традиционные центры обработки данных

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

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

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

Горизонтальное и вертикальное масштабирование

Развертывание приложений в GoGrid напоминает аналогичный процесс, выполняемый в собственной физической IT-инфраструктуре (центре обработки данных) предприятия, но с возможностью использования множества дополнительных средств, помогающих ускорить и упростить эти процессы. Как и в случае с другими облачными средами, вы имеете возможность расширения, известную под названием "горизонтального масштабирования" (horizontal scaling). Но, в отличие от многих других облачных сред, вы имеете возможность и "вертикального роста" (scale up), известную под названием "вертикального масштабирования" (vertical scaling), при которой используются не только возможности виртуализованной облачной среды, но и применения реальных, выделенных физических аппаратных устройств. В этом услуги GoGrid напоминают услуги традиционного физического центра обработки данных, где клиенты могут использовать комбинацию виртуальных и физических серверов. Иначе говоря, вы имеете возможность получения прямого доступа к физическому оборудованию с большими объемами RAM, высокоскоростные устройства хранения данных с непосредственным доступом (high-speed direct-attached-storage, DAS), а также большое количество независимых сервисов, основанных на виртуальных частных сетях (virtual private network, VPN).

Используйте правильно подобранный инструмент для решения правильно сформулированной задачи: виртуальные серверы для бесстатусных (stateless) рабочих нагрузок (таких как централизованная обработка, не связанная с сохранением данных), которые вы легко можете масштабировать горизонтально, и физические серверы — для рабочих нагрузок с сохранением статуса (stateful workloads), т. е. таких как манипулирование сохраняемыми данными, например операции над базами данных, которые проще масштабировать вертикально.

Рассмотрим основные факторы, которые обосновывают сказанное.

± Горизонтальное масштабирование (scaling out). Горизонтальному масштабированию проще всего поддаются серверы и такие приложения, которые сохраняют относительно мало информации о статусе, например Web-серверы, серверы приложений, а также все задания по пакетной обработке (batch processing). При этих типах рабочих нагрузок добавление дополнительного сервера обычно требует небольшого объема работ по планированию архитектуры, настройке и конфигурированию, или не требует их вообще. Таким образом, добавление дополнительных серверов предоставляет простой путь наращивания мощностей.

± Вертикальное масштабирование (Scaling up). В отличие от предыдущего случая, вертикальное масштабирование лучше всего подходит для таких приложений и типов рабочих нагрузок, которые связаны с хранением информации о состоянии — например, для баз данных и файл-серверов.  В таких случаях простое добавление дополнительного сервера не приводит к прямому наращиванию мощностей. Обычно в таких ситуациях требуется выполнять большие работы по переконфигурированию, менять  архитектуру или, по крайней мере, выполнять автоматическую балансировку данных о состоянии по новым серверам. Большинство ваших статусных данных хранятся именно на таких серверах, поэтому добавление нового сервера потребует динамической синхронизации терабайтов данных, что само по себе является нетривиальной задачей. Именно по этой причине обычно для таких задач желательно использовать более мощные серверы, нежели большее количество менее мощных. Кроме того, такие серверы имеют тенденцию быть не динамическими по своей природе, даже в облачной среде.

По только что описанным причинам GoGrid поддерживает обе шкалы масштабирования — и горизонтальную, и вертикальную. Горизонтальное масштабирование не всегда достаточно, а вертикальное требует выработки стратегии масштабирования. Компания Amazon тоже это понимает, поэтому для развертывания приложений в своей облачной среде AWS она предлагает различные масштабы серверов. Однако виртуализации внутренне присуща стратегия, известная под названием многоарендности (multitenancy), при которой подразумевается, что каждый отдельно взятый сервер предоставляет хостинг многим клиентам и многим приложениям. Если некоторый из компонентов вашего приложения может полностью использовать все вычислительные мощности современного физического сервера, то  не  имеет  смысла  запускать  это  приложение  на  сервере  виртуальном. В данном случае виртуализация будет приводить к неоправданным накладным расходам, и, если вам требуются бóльшие вычислительные мощности или объемы оперативной памяти (RAM), чем может предложить облачная среда, вам потребуется пересмотреть вашу архитектуру с тем, чтобы прибегнуть к горизонтальному масштабированию.

С другой стороны, большинство приложений на определенном этапе достигнут "потолка", при котором еще возможно вертикальное масштабирование, и тогда вы будете уже просто вынуждены прибегнуть к горизонтальному масштабированию. Вам потребуется соотнести потребность в ресурсах и доступные мощности, чтобы получить возможность применения модели горизонтального масштабирования. Но, поскольку закон Мура (Moore’s Law)1 все-таки никто не отменял, пройдет немало времени, прежде чем физическое оборудование перестанет удовлетворять требованиям стратегии вертикального масштабирования для большинства приложений.

Архитектуры для развертывания GoGrid

Типичная среда развертывания приложений GoGrid выглядит примерно так, как ваш собственный внутренний центр обработки данных (рис. П2.1).

Рис. П2.1. Роль виртуализации и облачной среды в GoGrid

В типичных физических центрах обработки данных серверы приложений взаимодействуют с Интернетом, чтобы дать пользователям возможности доступа к приложениям, в то время как внутренние серверы обработки данных защищены дополнительным уровнем, подобным демилитаризованной зоне (DMZ), и все системы имеют доступ по защищенным каналам к сетевым средствам хранения данных (NAS). Как и в традиционном центре обработки данных, в GoGrid имеются два

1 Закон Мура — эмпирический закон, выведенный в 1965 году Гордоном Муром (Gordon  Earle Moore). Он высказал предположение о том, что число транзисторов на кристалле будет удваиваться каждые 2 года.

Подробнее см. http://en.wikipedia.org/wiki/Moore’s_law, http://download.intel.com/museum/Moores_Law/Printed_Materials/Moores_Law_Backgrounder.pdf, http://www.ixbt.com/editorial/moorelaw40th.shtml. — Прим. перев.

сетевых сегмента (VLANs), один — для публичного доступа (frontend), другой — для внутреннего доступа (backend), использующий частные IP-адреса (RFC1918). Как и в традиционном центре обработки данных, здесь имеется NAS (GoGrid Cloud Storage) для использования под домашние каталоги, резервное копирование, архивы и другие потребности.

Вертикальное масштабирование (scaling up) в GoGrid не слишком сильно отличается от горизонтального (scaling out), за тем исключением, что высокопроизводительные базы данных, имеющие критически важное значение, работают на выделенных физических серверах, как показано на рис. П2.2.

Рис. П2.2. Роль физического хостинга в GoGrid

Web-приложения — в центре внимания

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

чая брандмауэры (firewalls), балансировщики нагрузки и VLAN. Большинство приложений, предназначенных для пакетной обработки данных, довольно хорошо работают в средах, предоставляющих информационные сервисы как коммунальные услуги (utility computing), и грид-средах (grid computing). GoGrid тоже может применяться для пакетной обработки данных, и, хотя пакетная обработка является важным компонентом многих Web-приложений, мы оптимизировали нашу среду под основные транзакционные Web-приложения, которые мы считаем намного более важными.

Сравнение подходов

При сравнении облачных центров (GoGrid) с сервисными инфраструктурами (AWS)1 важно учитывать как практику развертывания приложений в традиционных центрах обработки данных, так и природу развертываемых приложений.

Непосредственное сравнение

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

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

Функциональные возможности

Традиционный центр обработки данных

GoGrid (облачный центр обработки данных)

Amazon (сервисная инфраструктура)

Межсетевой экран (брандмауэр)

Аппаратный брандмауэр для защиты периметра

Аппаратный брандмауэр для защиты периметра (с начала 2009 года)

Индивидуально настроенный распределенный программный брандмауэр

Балансировщик нагрузки

Аппаратный балансировщик нагрузки

Аппаратный балансировщик нагрузки

Индивидуально развертываемый программный балансировщик нагрузки (возможно использование релиза от 2009 года для индивидуального сервиса балансировщика нагрузки)

1 См. также http://gogrid.ru/pricing/gogrid_vs_ec2.php и http://www.cloudtweaks.com/2010/09/cloud- computing-comparisons-between-aws-rackspace-and-gogrid/ (более полный сравнительный анализ, учитывающий также и возможности сервиса Rackspace, который будет рассматриваться в Приложении 3). — Прим. перев.

Таблица П2.1 (окончание)

Функциональные возможности

Традиционный центр обработки данных

GoGrid (облачный центр обработки данных)

Amazon (сервисная инфраструктура)

Изоляция сетей

VLAN

VLAN

Искусственное разделение по типу "VLAN" с использованием распределенного программного брандмауэра

Частные сети

Есть (VLAN)

Есть (VLAN)

Нет

Сетевые протоколы

Без ограничений

Без ограничений

Ограниченные возможности, нет многоадресной рассылки (multicast), нет широковещания

(broadcast), GRE1 и все, что относится к туннелированию, не работает

Выбор операционных систем

Без ограничений

С некоторыми ограничениями

С некоторыми ограничениями

DNS

Есть; внутрифирменное управление

Есть; управляется GoGrid

Нет

Постоянное локальное хранилище

Есть

Есть

Нет

Постоянное сетевое хранилище

Есть

Есть

Есть

Комбинирование виртуальных и физических серверов

Есть

Есть

Нет

Как видите, облачные архитектуры в стиле облачных центров во многом очень похожи на архитектуры традиционных центров обработки данных.

1 GRE (Generic Routing Encapsulation — общая инкапсуляция маршрутов) — протокол туннелирования сетевых пакетов, разработанный компанией Cisco Systems. Его основное назначение — инкапсуляция пакетов сетевого уровня сетевой модели OSI (Open Systems Interconnection) в IP-пакеты. Подробнее см. http://en.wikipedia.org/wiki/Generic_Routing_Encapsulation. — Прим. перев.

Практическое использование

Различия между облачными центрами и сервисными инфраструктурами станут более очевидны, если вы попробуете параллельно пользоваться GoGrid и AWS.

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

Напротив, подход "облачного центра обработки данных" (cloudcenter), практикуемый GoGrid, очень похож на использование консоли VMware VirtualCenter1 или любой другой системы управления виртуализацией. В дополнение к серверам, в GoGrid вы имеете возможность управления вашей сетью, DNS, накопителями, балансировщиками нагрузки, брандмауэрами2.

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

Что лучше подойдет вам?

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

1 Подробнее см. http://www.vmware.com/ru/products/vi/vc/. — Прим. перев.

2 Поддержка аппаратных брандмауэров в GoGrid появилась с 2009 года. Подробнее см. http://wiki.gogrid.com/wiki/index.php/Hardware_Firewalls.

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100