Поделиться через


Выберите целевую платформу Azure для размещения экспортируемых исторических данных

Одно из важных решений, которые вы принимаете во время миграции — определение места хранение исторических данных. Чтобы принять это решение, необходимо понять и сравнить различные целевые платформы.

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

Примечание.

Рекомендации в этой таблице применяются только к миграции журнала и не применяются в других сценариях, например, в сценарии долгосрочного хранения.

Базовые журналы и архив Azure Data Explorer (ADX) Хранилище BLOB-объектов Azure ADX + Хранилище BLOB-объектов Azure
Возможности: • Использование большинства основных возможностей журналов Azure Monitor с меньшей стоимостью.
• Базовые журналы хранятся в течение восьми дней и затем автоматически передаются в архив (в соответствии с исходным периодом хранения).
• Используйте задания поиска для поиска по петабайтам данных и поиска определенных событий.
• Для глубокого изучения определенного диапазона времени восстановите данные из архива. Затем данные будут доступны в горячем кэше для дальнейшей аналитики.
• И ADX, и Microsoft Sentinel используют язык запросов Kusto (KQL), позволяя запрашивать, агрегировать или сопоставлять данные на обеих платформах. Например, можно выполнить запрос KQL от Microsoft Sentinel для присоединения данных, хранящихся в ADX, к данным, хранящимся в Log Analytics.
• С помощью ADX вы можете существенно контролировать размер и конфигурацию кластера. Например, можно создать кластер большего размера для достижения более высокой пропускной способности приема или создать меньший кластер для управления затратами.
Хранилище BLOB-объектов оптимизировано для хранения больших объемов неструктурированных данных.
• Предлагает конкурентные затраты.
• Подходит для сценария, в котором ваша организация не определяет приоритеты специальных возможностей или производительности, например, если организация должна соответствовать требованиям к соответствию или аудиту.
• Данные хранятся в хранилище BLOB-объектов с низкими затратами.
• Вы используете ADX для запроса данных в KQL, что позволяет легко получить доступ к данным. Узнайте, как запрашивать данные Azure Monitor с помощью ADX
Удобство использования: Отлично

Параметры архива и поиска просты в использовании и доступны на портале Microsoft Sentinel. Однако данные не сразу доступны для запросов. Необходимо выполнить поиск, чтобы получить данные, которые могут занять некоторое время в зависимости от объема сканируемых и возвращаемых данных.
Хороший

Довольно просто использовать в контексте Microsoft Sentinel. Например, вы можете использовать книгу Azure для визуализации данных, распределенных между Microsoft Sentinel и ADX. Вы также можете запрашивать данные ADX с портала Microsoft Sentinel с помощью прокси-сервера ADX.
Бедный

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

Хотя оператор externaldata очень сложно использовать с большим количеством больших двоичных объектов для ссылки, использование внешних таблиц ADX устраняет эту проблему. При определении внешней таблицы распознается структура папок хранилища BLOB-объектов, что позволяет прозрачно запрашивать данные, содержащиеся в большом количестве разных BLOB-объектов и папок.
Накладные расходы на управление: Полностью управляемое

Параметры поиска и архива полностью управляемы и не создают дополнительных затрат на управление.
Высокий уровень

ADX является внешним для Microsoft Sentinel, который требует мониторинга и обслуживания.
Низкая

Несмотря на то, что для этой платформы требуется мало обслуживания, при выборе этой платформы добавляются задачи мониторинга и настройки, например, настройка управления жизненным циклом.
Средний

С помощью этой опции вы поддерживаете и отслеживаете ADX и Хранилище BLOB-объектов Azure, оба из которых являются внешними компонентами Microsoft Sentinel. Несмотря на то, что ADX иногда можно отключать, следует учитывать дополнительные затраты на управление, связанные с этой опцией.
Производительность. Средний

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

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

Предлагает два уровня производительности: Премиум или Стандартный. Хотя оба уровня являются вариантом для долгосрочного хранения, Стандартный уровень является более экономичным. Сведения о границах производительности и масштабируемости.
Низкая

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

Стоимость состоит из двух компонентов:
Стоимость приема данных. Каждый ГБ данных, переданных в базовые журналы, регулируется затратами на прием журналов Microsoft Sentinel и Azure Monitor, которые составляют около 1 долл. США. См. детализацию цен.
Затраты на архивацию. Стоимость данных на архивном уровне составляет около 0,02 долл. США/ГБ в месяц. См. детализацию цен.
Помимо этих двух компонентов затрат, если требуется частый доступ к данным, дополнительные затраты возникают при доступе к данным с помощью заданий поиска.
От высокой до низкой

• Так как ADX — это кластер виртуальных машин, плата взимается на основании вычислительных ресурсов, хранилища и сети, а также наценки ADX (см. детализацию цен). Таким образом, чем больше узлов вы добавляете в кластер и чем больше данных, тем выше стоимость.
• ADX также предлагает возможности автоматического масштабирования для адаптации к рабочей нагрузке по требованию. ADX также может воспользоваться ценами на зарезервированные экземпляры. Вы можете выполнять собственные вычисления затрат в Калькуляторе цен Azure.
Низкая

При оптимальной настройке Хранилище BLOB-объектов Azure имеет наименьшие затраты. Для повышения эффективности и экономии средств управление жизненным циклом Службы хранилища Azure можно использовать для автоматического размещения старых BLOB-объектов на более дешевые уровни хранилища.
Низкая

В этом случае ADX выступает только в качестве прокси-сервера, поэтому кластер может быть небольшим. Кроме того, можно отключить кластер, если вам не нужен доступ к данным, и запускать его только при возникновении необходимости в доступе.
Получение доступа к данным: Задания поиска Прямые запросы KQL Оператор KQL externaldata Измененные запросы KQL
Сценарий: Случайный доступ

Актуально для сценариев, в которых не требуется выполнять тяжелую аналитику или активировать правила аналитики, а доступ к данным требуется только иногда.
Частый доступ

Актуально для сценариев, где часто требуется доступ к данным, и необходимо управлять размером и настройкой кластера.
Соответствие/аудит

• Оптимально для хранения больших объемов неструктурированных данных.
• Актуально для сценариев, в которых не требуется быстрый доступ к данным или высокая производительность, например в целях соответствия или аудита.
Случайный доступ

Актуально для сценариев, в которых вы хотите воспользоваться низкой стоимостью Хранилища BLOB-объектов Azure и обеспечить относительно быстрый доступ к данным.
Сложность — Очень низкий Средняя Низкий Высокий
Готовность: Общедоступная версия Общедоступная версия Общедоступная версия Общедоступная версия

Общие рекомендации

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

Использование журналов приема

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

Рассмотрим следующие три общих сценария:

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

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

Скорость миграции

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

Просмотрите компоненты и факторы, определяющие скорость миграции.

Источник данных

Источник данных обычно является локальной файловой системой или облачным хранилищем, например S3. Производительность хранилища сервера зависит от нескольких факторов, таких как технология дисков (SSD и HDD), характер запросов ввода-вывода и размер каждого запроса.

Например, производительность виртуальных машин Azure составляет от 30 МБ в секунду для небольших номеров SKU виртуальных машин до 20 ГБ в секунду для некоторых из дисков NVM Express (NVMe). Узнайте, как спроектировать виртуальную машину Azure для высокой производительности хранилища. Вы также можете применить большинство концепций к локальным серверам.

Вычислительные ресурсы

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

  • Вертикальное масштабирование. Увеличение мощности одного сервера путем добавления дополнительных ЦП или увеличения скорости ЦП.
  • Горизонтальное масштабирование. Вы добавляете дополнительные серверы, что повышает параллелизм процесса копирования.

Целевая платформа

Каждая из целевых платформ, рассмотренных в этом разделе, имеет свой профиль производительности.

  • Базовые журналы и архив Azure Monitor. По умолчанию базовые журналы можно отправлять в Azure Monitor примерно в 1 ГБ в минуту. Эта скорость позволяет принять приблизительно 1,5 ТБ в день или 43 ТБ в месяц.
  • Azure Data Explorer. Производительность приема зависит от размера подготовленного кластера и применяемых параметров пакетной обработки. Узнайте о рекомендациях по приему, включая производительность и мониторинг.
  • Хранилище BLOB-объектов Azure. Производительность учетной записи Хранилище BLOB-объектов Azure может значительно отличаться в зависимости от количества и размера файлов, размера задания, параллелизма и т. д. Узнайте, как оптимизировать производительность AzCopy и Службы хранилища Azure.

Объем данных

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

Чтобы определить минимальную продолжительность миграции и место возникновения узких мест, рассмотрите объем данных и скорость приема целевой платформы. Например, вы выбираете целевую платформу, которая может принять 1 ГБ в секунду и перенести 100 ТБ. В этом случае миграция займет не менее 100 000 ГБ, умноженное на 1 ГБ в секунду. Разделите результат на 3600. Это даст 27 часов. Это правильное вычисление, если остальные компоненты в конвейере, такие как локальный диск, сеть и виртуальные машины, могут выполняться со скоростью 1 ГБ в секунду.

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

Из этой статьи вы узнали, как сопоставить правила переноса из QRadar с Microsoft Sentinel.