Выберите целевую платформу 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.