Расширение локальных решений для работы с данными в облако

  • Статья

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

В этой статье описываются некоторые рекомендации и рекомендации по управлению данными в гибридном облачном решении.

Сценарии использования гибридного решения

Рассмотрите возможность использования гибридного решения в следующих сценариях:

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

Сложности

  • Создание согласованной среды с точки зрения безопасности, управления и разработки и предотвращения дублирования работы

  • Создание надежного, низкой задержки и безопасного подключения к данным между локальными и облачными средами

  • Репликация данных и изменение приложений и средств для использования правильных хранилищ данных в каждой среде

  • Защита и шифрование данных, размещенных в облаке, но доступ к ним выполняется из локальных систем или наоборот.

Локальные хранилища данных

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

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

  • Стоимость. Стоимость хранилища в Azure может быть значительно меньшей, чем стоимость обслуживания хранилища со схожими характеристиками в локальном центре обработки данных. Многие компании имеют инвестиции в высокопроизводительные сети SAN, поэтому эти преимущества затрат могут не достичь полного плода до тех пор, пока существующее оборудование не устаревает.

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

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

Расширение хранилищ данных в облако

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

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

Третий вариант — хранить все данные локально. Однако для размещения приложений необходимо использовать облачные вычисления. С помощью этого параметра вы размещаете приложение в облаке и подключаете его к локальному хранилищу данных через безопасное подключение.

Azure Stack

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

Azure и Azure Stack подходят для следующих вариантов использования:

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

  • Облачные приложения, соответствующие различным нормам. Разрабатывайте и развертывайте приложения в Azure с гибкими возможностями локального развертывания этих же приложений в Azure Stack для обеспечения нормативных требований или требований политики.

  • Локальная облачная модель приложения. Обновляйте и создавайте новые приложения или расширяйте имеющиеся с помощью Azure. Используйте согласованные процессы DevOps в облаке Azure или локальной среде Azure Stack.

Хранилища данных SQL Server

При запуске SQL Server в локальной среде можно использовать Хранилище BLOB-объектов Azure для служб резервного копирования и восстановления. Дополнительные сведения см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure. Эта возможность обеспечивает неограниченное хранилище вне сайта и возможность совместного использования одних и тех же резервных копий между SQL Server, работающими в локальной среде и SQL Server, работающими на виртуальной машине в Azure.

База данных SQL Azure — это управляемая реляционная база данных как услуга. Так как База данных SQL использует подсистему Microsoft SQL Server, приложения могут получать доступ к данным одинаково с обоими технологиями. База данных SQL также можно сочетать с SQL Server полезными способами. Например, функция Stretch Database SQL Server позволяет приложению получить доступ к одной таблице в базе данных SQL Server, а некоторые или все строки этой таблицы могут храниться в База данных SQL. Эта технология автоматически перемещает данные, доступ к которым не осуществлялся на протяжении определенного периода времени, в облако. Приложения, считывающие эти данные, не знают, что все данные были перемещены в облако.

Обслуживание хранилищ данных в локальной среде и в облаке может быть нелегкой задачей, если вы захотите синхронизировать данные. Эту проблему можно решить с помощью Синхронизация данных SQL, службы, созданной на основе База данных SQL, которая позволяет синхронизировать данные, которые вы выбираете, двунаправленно между несколькими базами данных SQL Azure и экземплярами SQL Server. Хотя Синхронизация данных упрощает актуальность данных в этих различных хранилищах данных, их не следует использовать для аварийного восстановления или переноса из локальной среды SQL Server в База данных SQL.

Для аварийного восстановления и непрерывности бизнес-процессов можно использовать группы доступности AlwaysOn для репликации данных в двух или более экземплярах SQL Server, некоторые из которых могут работать на виртуальных машинах Azure в другом географическом регионе.

Сетевые папки и файловые хранилища данных

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

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

Azure StorSimple предоставляет наиболее полное решение интегрированного хранилища для управления задачами хранилища на локальных устройствах и в облачном хранилище Azure. StorSimple — это эффективное, экономичное и легко управляемое решение сети хранения данных (SAN), которое устраняет многие проблемы и расходы, связанные с корпоративным хранилищем и защитой данных. Оно использует собственное устройство StorSimple серии 8000, интегрируется с облачными службами и предоставляет набор встроенных средств управления.

С помощью службы Файлы Azure вы также можете использовать локальные сетевые папки вместе с облачным хранилищем файлов. Служба "Файлы Azure" предоставляет полностью управляемые файловые ресурсы, доступ к которым можно получить с помощью стандартного протокола SMB (иногда его называют CIFS). Вы можете подключить службу "Файлы Azure" как файловый ресурс на локальном компьютере или использовать ее с имеющимися приложениями, которые осуществляют доступ к локальным файлам и файлам сетевой папки.

Чтобы синхронизировать общие папки в Файлы Azure с локальными серверами Windows, используйте Синхронизация файлов Azure. Одним из основных преимуществ Синхронизация файлов Azure является возможность распределения файлов между локальным файловыми серверами и Файлы Azure. Эта возможность позволяет хранить только самые новые и последние доступ к файлам локально.

Дополнительные сведения см. в статье Выбор между большими двоичными объектами Azure, службой файлов Azure и дисками Azure.

Гибридные сети

В этой статье рассматриваются гибридные решения данных, но другое решение заключается в том, как расширить локальную сеть в Azure. Дополнительные сведения об этом аспекте гибридных решений см. в следующих ресурсах:

Соавторы

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

Автор субъекта:

Следующие шаги