Инженерная инфраструктура центров обработки данных (ЦОД)

Сегодня Amazon Web Services (AWS) объявила о выпуске бета-версии своего нового шлюза хранилища данных, который позволяет вам получать доступ к сервисам Amazon S3 (Simple Storage Services) из разных приложений с помощью устройства, устанавливаемого в вашем дата-центре. Запустив эту бета-версию, Amazon вошла в число других компаний, предоставляющих автономные шлюзы (например, Nasuni), а также тех, кто исчез с рынка (например, Cirtas). Помимо поставщиков шлюзов, есть также те, которые включили возможность доступа к облачным сервисам в свои программные продукты (например, Jungle Disk, позволяющий получать доступ к облачным сервисам Rackspace и Amazon S3, вместе с Commvault Simpana Cloud connector и др.). Есть также поставщики, которые включили облачные шлюзы в свои системы хранения данных, такие как TwinStrata. Даже компания EMC включилась в игру, добавив поддержку облачного доступа в некоторые из своих продуктов.

Определение шлюза облачного хранилища данных

Перед продолжением давайте вернемся немного назад и постараемся ответить на главный вопрос – что такое шлюз облачного хранилища данных? Доступ к облачным сервисам типа хранилища данных осуществляется по сети, публичной или частной. Тип облачного сервиса, к которому необходимо получить доступ (рис. 1) будет определять, что вам нужно. Так, к одним сервисам можно получить доступ с помощью обычного веб-браузера, в то время как для доступа к другим сервисам могут требоваться съемные модули. Для доступа к одним облачным сервисам или ресурсам может требоваться загрузка приложения, агента или другого инструментального средства, тогда как для доступа к другим сервисам может требоваться устанавливаемое на территории предприятия устройство или шлюз.

     ПО и шлюзы или устройства облачного доступа применяются для обеспечения доступа к облачным хранилищам данных локальных приложений. Шлюзы, помимо обеспечения облачного доступа, предоставляют функции репликации, snapshot и другие функциональные возможности сервиса хранения данных. Облачные шлюзы или серверное ПО включают инструменты от BAE, Citrix, Gladinet, Mezeo, Nasuni, Openstack, Twinstrata и Zadara. Кроме облачных шлюзов или облачных точек присутствия (cpops), доступ к публичным сервисам также поддерживается с помощью разных программных инструментов. Многие инструментальные средства защиты информации, в том числе резервирование/восстановление, архивирование, репликация и другие функции, включают или планируют включить поддержку доступа к разным публичным сервисам, таким как Amazon, Google, Iron Mountain, Microsoft, Nirvanix или Rackspace.

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

     Например, я могу использовать базовые функции своих учетных записей в системах хранения данных Amazon S3 или Rackspace с помощью их веб-инструментов и других предоставленных инструментальных средств. Однако для выполнения резервного копирования и восстановления я использую инструментальные средства, предоставляемые сервисным провайдером, и я имею дело с двумя разными сервисами облачных систем хранения данных. Этот инструмент представляет собой интерфейс для определения того, что необходимо резервировать, защищать и восстанавливать, а также разрешения общих (публичных или частных) устройств хранения данных и сетевых дисков. Кроме предоставления интерфейса (Рис. 2), этот инструмент также использует специфические API и протоколы других сервисов, включая функции PUT (создать или обновить контейнер), POST (обновить заголовок или мета данные), LIST (извлечь информацию), HEAD (доступ к мета данным), GET (извлечь данные из контейнера) и DELETE (удалить контейнер). Обратите внимание на то, что реальное поведение и функциональные возможности API будут зависеть от сервисного провайдера. Важность приведенного выше примера состоит в том, что когда вы знакомитесь с провайдерами облачных систем хранения данных, вам могут встречаться упоминания операций PUT, POST, LIST, HEAD, GET и DELETE, а также таких сервисов как пропускная способность и доступность. Некоторые сервисы могут включать неограниченное число операций, тогда как другие сервисы могут брать дополнительную плату за выполнение обновлений, листинг или извлечение ваших данных. Зная такие базовые облачные функции как PUT или POST и GET или LIST, можно получить лучшее представление о том для чего они используются, а также о том какую роль они играют в оценке разных сервисов, ценообразовании и тарифных планах.

     В зависимости от типа облачного сервиса, могут использоваться разнообразные протоколы или интерфейсы, в том числе iSCSI, NAS NFS, HTTP или HTTPs, FTP, REST, SOAP, Bit Torrent, API и платформа PaaS, включающая поддержку.NET или набор команд SQL, в дополнение к XM, JSON или другим форматам данных. Виртуальные машины (VM) можно перемещать в облачный сервис с использованием функций передачи файлов или возможностей провайдера по загрузке образов виртуальных машин. Например, такие VM как VMDK или VHD подготавливается локально в вашей среде, а затем передаются провайдеру для выполнения. Облачные сервисы могут давать программу или утилиту для доступа, которая позволяет вам определять время, место и метод защиты данных, по аналогии с другими средствами резервного копирования или архивирования.

     В некоторые стандартные инструменты резервного копирования или архивирования включена поддержка непосредственного, или с помощью стороннего устройства, доступа к облачным сервисам хранения данных (IaaS), например, Amazon, Rackspace и другие.

     Сторонние устройства доступа или шлюзы позволяют существующим инструментам выполнять чтение и запись данных в облачной среде с использованием для этой цели стандартных интерфейсов, например, NAS (NFS и/или CIFS) или iSCSI (Block), которые преобразовываются в формат серверной части облачного сервиса. Например, если вы станете абонентом Amazon S3, хранилище выделяется в виде объектов, и для их управления используются разнообразные инструментальные средства. Облачное ПО доступа или устройство знает как организовать связь с IaaS Storage APIs и абстрагирует их от методов их использования.

     Программные инструменты доступа или шлюзы, в дополнение к трансляции или преобразованию данных между облачными API, форматируют ваши приложения, включая обеспечение безопасности с помощью шифрования, оптимизацию полосы пропускания и сокращение занимаемого данными объема памяти, например, сжатие и дедупликация. В число других функций входит составление отчетов, инструменты управления, которые поддерживают различные интерфейсы, протоколы и стандарты, включая SNMP или SNIA, Storage Management Initiative Specification (SMIS) и Cloud Data Management Initiative (CDMI).

Первое мнение — интересное, неплохое предложение Amazon, я готов устанавливать и начинать его тестирование сегодня

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

     Это подразумевает использование действующих учетных записей Amazon для упрощения процессов получения, управления, текущего биллинга, а также использования их инфраструктуры. Идея автономного шлюзового устройства (например, оно не обязательно должно быть составным элементом специального инструмента резервного копирования, архивирования, репликации или другого инструмента управления данными), заключается в том, что эту технологию можно использовать для соединения серверов и систем хранения данных в действующем дата-центре и пересылки копии данных в Amazon S3. В дополнение к пересылке данных в S3, интегрирование этой функциональной возможности с другими сервисами AWS должно будет облегчать интеграцию с Elastic Cloud Compute (EC2) и Elastic Block storage (EBS), включая snapshot для защиты данных. Таким образом, после поверхностного ознакомления мое первое мнение о шлюзе хранения данных от AWS было неплохим, а после более детального рассмотрения у меня создалось второе мнение.

Второе мнение — в реальности это требует замедления работы и больше надомной работы

Более детальное ознакомление с различными общедоступными материалами (в примечании можно комментировать или обсуждать только объявленные события или публичные материалы) привело к возникновению второго мнения о желании и необходимости копать глубже, основанные на некоторых предупреждениях. Конечно же, теперь надо отдать дань справедливости Amazon и помнить, что это бета-версия и поскольку при первоначальном ознакомлении можно легко пропустить сообщение о том, что на самом деле это бета-версия, будем надеяться, что все еще может измениться.

     Оставив в стороне ценовую политику, которая имеет значение как в случае любого облачного или администрированного сервиса хранения данных, вы должны будет создать модель анализа затрат, как в случае аренды физического хранилища данных, узнать стоимость ежемесячной платы за шлюз вместе со связанным с ним физическим сервисом под управлением VMware ESXi, который вам нужно будет предоставить. Есть шансы, что если вы представляете собой SMB среднего размера, у вас есть физическая машина (PM), на которую можно сбросить копию ESXi, если у вас уже нет места для еще нескольких виртуальных машин на работающем сервере.

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

     Еще одной вещью, о которой следует помнить при рассмотрении шлюза хранения данных AWS, является то, что он не может заменить собой локальную систему хранения данных (если вы, конечно, не переместили свои приложения в Amazon EC2 и EBS), а делает копию сохраненных локально данных и отправляет ее в пул Amazon S3. Это может служить хорошим решением для обеспечения высокого уровня доступности (HA), непрерывности бизнеса (BC), восстановления после стихийных бедствий (DR) и соответствия среди прочих требований управления данными. Тем не менее, в своей модели затрат вы должны иметь в виду, что вы не заменяете свое локальное хранилище, а дополняете его облачным сервисом, что следует рассматривать как расширение своего частного облака, которое теперь можно считать гибридным облаком.

Обсуждение защиты облачных данных

По непроверенным данным, я использую похожую модель, в которой я использую сервис (Jungle Disk), в котором критические копии моих данных отправляются в этот сервис, который, в свою очередь, размещает копии в Rackspace (материнская компания Jungledisks) и Amazon S3. Что и куда отправляется зависит от установленных мною разных политик. У меня также есть локальные резервные копии, а также главную золотую копию на случай восстановления после аварии, хранящуюся вне территории компании. Суть том, что, в случае необходимости, я смогу быстро получить хорошую копию данных от своих поставщиков облачных сервисов вне зависимости от своего местоположения, если локальная копия плохая. С другой стороны, как показал опыт, если я не располагаю достаточной полосой пропускания, и мне нужно быстро вернуть сотни гигабайт или терабайт данных, мне лучше вернуть свою главную копию, а потом применять меньшее число обновлений меньшего размера от облачного сервиса. Иными словами, технологии дополняют друг друга.

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

     Возвращаясь к шлюзу AWS и моему второму мнению, я понял, что сначала оно казалось замечательным. Однако, потом я понял, что он поддерживает только iSCSI, и, поскольку я ничего не имею против iSCSI, мне он понравился и я рекомендовал использовать его, где это применимо, хотя я сам его не использую. Я хотел бы, чтобы шлюз поддерживал NAS (либо NFS и/или CIFS), что в моем сценарии могло бы облегчить моим приложениям, серверам и системам использование сервисов AWS, аналогично тому, что я могу делать с помощью других своих шлюзов через посредство разных программных инструментов. Если в системе серверы уже используют iSCSI, необходимую для использования шлюза AWS Storage Gateway, то это не проблема, тогда как для других подготовка своего окружения для использования этой функциональной возможности будет требовать затрат времени.

     Мое внимание привлек другой момент, проблемность которого может зависеть от объема памяти в вашей среде, а именно то, что шлюз iSCSI поддерживает 12 томов размером 1 ТБ каждый, то есть максимальный размер памяти будет 12 ТБ. Эту проблему можно обойти с помощью использования нескольких шлюзов, однако, здесь стоит рассматривать соотношение повышенной сложности и получаемой выгоды.

Третье мнение — копайте глубже, узнавайте больше, задавайте разные вопросы

Это привело к появлению у меня третьего мнения о необходимости получения еще более подробных сведений о том, что шлюз AWS Storage Gateway может и не может делать для разнообразных окружений. Я смогу увидеть среды, для которых он будет подходить, и в то же время среды, в которых его нельзя использовать, по крайней мере, в его бета-версии. Тем временем, занимайтесь исследованиями, следите за другими возможностями, которые после запуска шлюза Amazon могут внести оживление на рынке поставщиков автономных или встроенных решений облачных шлюзов.

Что нужно для использования шлюза AWS?

В дополнение к созданию учетной записи в S3, вам нужно будет приобрести месячный абонемент на шлюзовое устройство хранения данных, которое устанавливается на виртуальной машине с гипервизором VMware ESXi. Требования: гипервизор VMware ESXi (v4.1) на физической машине с ОЗУ размером не менее 7.5 ГБ и четыре виртуальных процессора, назначенных для VM устройства с 75 ГБ свободного места на диске для установки образа Open Virtual Alliance (OVA) и данных. Вам также будет требоваться соответствующее подключение к Amazon. Вам также будут требоваться инициаторы iSCSI на базе Windows server 2008, Windows 7 или Red Hat Enterprise Linux.

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

     Вот несколько заключительных соображений, советов и комментариев:

• Поздравления Amazon за представление и запуск брендового шлюза AWS.
• Amazon повышает доверие к облачным системам.
• Сначала мне понравилась идея использования шлюза, который позволяет всем моим системам использовать мои пулы в S3, вместо использования функций шлюзового доступа, встроенных в разные инструменты, типа программы резервного копирования, или веб-инструментов Amazon. Мне также понравилась идея простого в установке и использовании шлюза, который мог бы обеспечивать мой экономичный рост.
• Имейте в виду, что это решение или, по крайней мере, его бета-версия не заменяет собой действующую систему iSCSI, а дополняет ее.
• Я надеюсь Amazon внимательно прислушивается к пожеланиям своих настоящих и будущих клиентов относительно необходимости развивать функциональные возможности.
• Это объявление должно придать силы некоторым производителям облачных устройств, а также тех, кто имеет встроенные функциональные возможности для Amazon и других провайдеров.
• Не забывайте о сетевых сервисах и оптимизации для отправки данных, а также для извлечения данных во время аварии или восстановления небольшого файла.
• Концептуально шлюз AWS совсем не отличается от устройств, которые делают snapshot и выполняют другие функции локальной и удаленной защиты, например, шлюзы от Actifio, EMC (Recoverpoint), Falconstor, или специализированные шлюзы (Nasuni и другие).
• Вот ссылка на часто задаваемые вопросы (ЧАВО) по встроенным шлюзам хранения данных от AWS.
• Если бы предлагались шлюзы AWS с интерфейсом NAS, я бы, наверное, активировал его сегодня же, даже не принимая во внимание другие требования и затраты.
• Я еще не сформулировал свое четвертое мнение, что может занять некоторое время, и возможно, если мне удастся убедить Amazon помочь в продаже некоторого количества моих книг, что позволит мне заработать немного денег и начать тестирование всего решения с использованием своих учетных записей S3, EC2 и EBS, я мог бы сделать это в будущем, а пока буду продолжать исследования.
• Для получения дополнительных сведений о бета-версии шлюза AWS Storage Gateway beta, см. бесплатную веб-трансляцию Amazon от 23 февраля 2012 г.

    Дополнительную информацию по облачной защите данных, сокращению занимаемого данными объема памяти, облачных шлюзах, доступе и управлении см. в моей книге Cloud and Virtual Data Storage Networking (CRC Press), с которой можно ознакомиться в форме электронного издания Amazon Kindle, а также в форме печатного издания в твердой обложке, также доступного на Amazon.com.

Автор статьи — Greg Shultz, известный эксперт и автор ряда книг.

Оригинал статьи: http://www.datacenterjournal.com/dcj-expert-blogs/aws-amazon-storage-gateway-first-second-and-third-impressions/