В этой статье представлен технический обзор использования Microsoft Azure для поддержки и улучшения вычислений сетки рисков в банковском секторе. В статье рассматриваются рекомендуемые системы и высокоуровневые архитектуры.
Данный документ предназначен для Архитектуры решений, а также в некоторых случаях для технических руководителей, кому необходимо больше узнать о решениях рекомендованных для вычисления риска.
Введение
Модели анализа финансовых рисков обычно обрабатываются как пакетные задания. Они имеют тяжелые вычислительные нагрузки, которые создают высокий спрос на вычислительные мощности, доступ к данным и анализ. Спрос на вычисления сетки рисков часто растет со временем, и потребность в вычислительных ресурсах увеличивается вместе с ним.
Широкий спектр доступных продуктов и служб в Azure означает, что для большинства проблем может быть более чем одно решение. В этой статье представлен обзор технологий, шаблонов и методик, которые наиболее эффективны для решения вычислений сетки рисков в банковском секторе, использующего Microsoft пакетная служба Azure.
пакетная служба Azure — это бесплатная служба, которая предоставляет экономичные и безопасные решения. Решения предназначены как для инфраструктуры, так и для различных этапов пакетной обработки, которые обычно используются с моделями вычислений сетки рисков. Пакетная служба Azure может снабжать, расширять или даже заменять текущие затраты локальных вычислительных ресурсов с помощью гибридных сетей или перемещая весь процесс пакетной службы в Azure. Данные могут проходить вверх и вниз от облака или оставаться в локальной среде. Другие данные могут обрабатываться вычислительными узлами в модели с ускорением в облако, когда локальные ресурсы выполняются с низким уровнем.
Анатомия пакетная служба Azure запуска
При выполнении пакетной службы задействованы по крайней мере два приложения. Одно приложение (выполняется в головном узле) отправляет задание в пул и иногда организовывает вычислительные узлы. Механизмы управления можно настроить с помощью портала Azure. Другое приложение выполняется вычислительными узлами в качестве задачи (см. рисунке 1).
Приложение вычислительного узла выполняет задачи файлов моделирования рисков параллельной обработки. На вычислительных узлах можно устанавливать и выполнять больше чем одно приложение.
Эти приложения можно отправлять через API пакетной службы напрямую через портал Azure или с помощью команд Azure CLI для пакетной службы.
Рисунок 1. Распределенные вычисления типа "решетка" пакетной службы Azure
Запуск пакетная служба Azure состоит из нескольких логических элементов. На рисунке 2 показана логическая модель пакетного задания. Пул — это контейнер для виртуальных машин участвующих в выполнении пакетной службы и подготавливающих к работе виртуальные машины вычислительных узлов. Пул также является контейнером для приложений, установленные на вычислительных узлах. Задания создаются и выполняются в пуле. Задания выполняют задачи. Задачи — это запуск рабочего приложения и вызывается инструкцией командной строки.
Рабочей роли приложение устанавливается на вычислительный узел при его создании.
Рис. 2. Модель логической пакетной концепции
При выполнении задания, пул подготавливает к работе любую необходимую рабочую роль виртуальных машин и устанавливает рабочую роль приложений. Задание назначает задачи этим вычислительным узлам, которые, в свою очередь, выполняют инструкцию командной строки (CLI). Скрипт CLI обычно вызывает установленные приложения или скрипты.
После использования пакетной службы следует описания модели, как описано ниже.
- Создание группы ресурсов, которая будет включать ресурсы пакетной службы.
- Создание учетной записи пакетной службы в группе ресурсов.
- Создание связанной учетной записи хранения.
- Создайте пул, в котором можно подготовить рабочие виртуальные машины.
- Отправка приложения или скрипта вычислительного узла в пул.
- Создание задания для назначения задач виртуальным машинам в пуле.
- Добавление задания в пул.
- Начало выполнения пакетной службы.
- На вычислительных узлах задание ставит задачи в очередь на выполнение.
- Вычислительные узлы выполняют задачи, как только появляется доступ к виртуальным машинам.
На рисунку 3 отображается этот процесс.
Рис. 3. Модель логической пакетной концепции
После завершения задачи необходимо удалить вычислительные узлы чтобы не взималась плата за то время пока служба не используется. Чтобы через код или портал удалить их, можно удалить содержащий их пул, который удалит рабочие роли виртуальных машин.
Более подробные пошаговое руководство по началу работы с пакетной службой, 5-минутные краткие руководства по использованию процесса на нескольких языках, а также о том, как использовать портал Azure.
Планирование процесса пакетной службы
Пакетная служба Azure имеет планировщика встроенного в планирование каждого запуска, который можно задать на портале или с помощью API. Планировщик задания пакетной службы может определить несколько расписаний для выполнения нескольких заданий. Каждое задание имеет собственные свойства, например, в том случае когда задание начинается и заканчивается. Расписания заданий можно задать на повторяющиеся интервалы или для однократного выполнения.
Во многих банковых системах распределенных вычислений типа "решетка" уже есть свои собственные службы расписаний. Нет надобности в перемещении планировщика в Azure. Это может работать легко, так как пакетная служба Azure можно вызывать вручную или с помощью пакета SDK. Эта возможность позволяет планировать все еще локальные процессы и позволяет обрабатывать рабочие нагрузки в Azure.
Пакетная обработка может выполняться по предопределенному расписанию или по запросу. В любом случае не нужно сохранять виртуальные машины вычислительных узлов в живых, если они не используются. При использовании сотен, если не тысяч вычислительных узлов виртуальных машин, значительные затраты могут быть реализованы путем отмены подготовки серверов при выполнении очередных задач.
Приложения вычислительных узлов
Чтобы запускаться при вызове задачи, вычислительным узлам необходимо приложение. Эти приложения написаны предприятием для выполнения рабочих заданий при установке на рабочие роли. В вычислениях сетки рисков для банковских сценариев это приложение часто принимает на себя задание преобразования данных в форматы, особенно подходящие для нижней аналитики или другой обработки.
При предоставлении приложению пулу для распространения на вычислительные узлы он передается в пакет приложения. Пакет приложения может быть другой версией ранее отправленного пакета приложения. На один вычислительный узел можно установить более чем один пакет приложения. Задание содержит пакеты приложения для загрузки на рабочих компьютерах.
Версии могут управлять развертыванием пакета приложения. Если несколько версий пакета приложения были загружены в пул, в пакете выполнения для использования при выполнении пакетной службы можно указать конкретную версию, как показано на рисунке 4. Это необходимо в средах аудита или когда бизнесу нужно воспроизвести предыдущее выполнение. Его также можно использовать в целях отката если существуют ошибки для рабочей роли приложений.
Рисунок 4. Управление версиями приложений задач вычислительных узлов
Пакет приложения передается в пул в виде файла .zip. Файл содержит двоичные файлы приложения и вспомогательные файлы, необходимые для выполнения задач. Существует два область для пакетов приложений. В области пула или в области задач можно назначить пакет приложения.
Пакеты приложений пула
Эти пакеты развертываются в пуле на каждом вычислительном узле. При подготовке, перезагрузке или повторном создании виртуальной машины вычислительного узла устанавливается новая копия всех пакетов приложений пула, если обновленное приложение существует. Один или несколько пакетов приложений можно назначить пулу, это значит, что вычислительным узлам будут назначены все пакеты.
Задачи пакетов приложений
Пакеты приложений, предназначенные для уровня задач, устанавливаются только на вычислительных узлах, запланированных выполнять задачи. Задачи пакетов приложения предназначены для использования при выполнении более одного задания в пуле.
Приложения задач полезны при агрегации данных, созданных заданиями уровня пула. Эти приложения могут быть релевантными в сценариях вычислений сетки рисков. Например, приложение задачи может выполнять набор вычислений рисков, создающих данные, которые будут использоваться позже в рабочем процессе вычисления рисков.
Масштабирование пакетных заданий
Банки часто выполняют анализ риска запуска пакетов у выходные дни или ночью, когда вычислительные ресурсы используются недостаточно. Пока эта модель работает в некоторых случаях, она может быстро перерасти, требуя большего капитала, для добавления большего количества рабочих машин в сетку.
Если выполнение заданий пакетная служба Azure занимает слишком много времени или если требуется больше вычислительной мощности в пакетной службе, Azure предлагает несколько вариантов.
- Выделите для горизонтального увеличения масштаба дополнительные компьютеры вычислительных узлов.
- Выделите для масштабирования более мощные компьютеры вычислительных узлов. Компьютеры Azure можно подготовить для удовлетворения потребностей высокой производительности для ядер и памяти и даже вычислительной мощности GPU.
Примечание. Использование пакета Microsoft HPC с пакетной службой является более сложной моделью и не рассматривается в этой статье.
В кластере пакетной обработки может быть не более двух виртуальных машин обработки. Кроме того, вы можете выполнять тысячи одновременных задач на тысячах вычислительных узлов виртуальной машины с десятками тысяч ядер. Каждая виртуальная машина отвечает за выполнение одной задачи в одно и тоже время. Количество виртуальных машин в пуле можно масштабировать вручную или автоматически, как указано при увеличении нагрузки или уменьшении нагрузки.
Ускорение в облаке
При выполнении вычислительных ресурсов в локальной сетке на низком уровне из-за выполнения большего задания анализа, ускорение в облаке предлагает способ расширить эти ресурсы, добавляя в Azure дополнительные вычислительные узлы. Ускорение работы в облаке — это модель, в которой частные облака или инфраструктура распределяют рабочую нагрузку на облачные серверы, когда спрос на локальные ресурсы высок.
Эти вычислительные узлы предварительно можно настроить как виртуальные машины Windows или Linux, чтобы подготовить их к работе на платформе IaaS Azure. Кроме того, серверы можно создать и автоматически настроить для работы с существующими инвестициями, например, Tibco Gridserver и IBM Symphony.
Формулы автоматического масштабирования
Эту эластичность можно настроить на портале Azure или с помощью статьи Создание формулы автоматического масштабирования для масштабирования вычислительных узлов в пуле пакетной службы. Формулы автоматического масштабирования — это скрипты, переданные планировщику пакетной обработки для точного управления реакцией пакетной службы. Автоматическое масштабирование пула вычислительных узлов выполняется путем связывания узлов с формулами автомасштабирования.
В следующем примере используется автоматическая формула масштабирования, направленная на автоматическое масштабирование для запуска с одной виртуальной машины и масштабирования до 50 виртуальных машин по мере необходимости. При завершении задач виртуальные машины поочередно высвобождаются, и формула автомасштабирования сжимает размер пула.
startingNumberOfVMs = 1;
maxNumberofVMs = 50;
pendingTaskSamplePercent = $PendingTasks.GetSamplePercent(180 * TimeInterval_Second);
pendingTaskSamples = pendingTaskSamplePercent < 70 ? startingNumberOfVMs : avg($PendingTasks.GetSample(180 * TimeInterval_Second));
$TargetDedicatedNodes=min(maxNumberofVMs, pendingTaskSamples);
Другие способы масштабирования
Автоматическое масштабирование также можно включить с помощью командлета PowerShell Enable-AzureBatchAutoScale. Командлет Enable-AzureBatchAutoScale позволяет автоматическое масштабирование указанного пула. Это представлено в примере ниже.
- Первая команда определяет формулу и затем сохраняет ее в переменной
$Formula. - Вторая команда включает автоматическое масштабирование в пуле с именем
RiskGridPoolиспользуя формулу в$Formula.
C:\> $Formula = ‘startingNumberOfVMs = 1;
maxNumberofVMs = 50;
pendingTaskSamplePercent = $PendingTasks.GetSamplePercent(180 * TimeInterval_Second?WT.mc_id=gridbanksg-docs-dastarr);
pendingTaskSamples = pendingTaskSamplePercent < 70 ? startingNumberOfVMs : avg($PendingTasks.GetSample(180 * TimeInterval_Second));
$TargetDedicatedNodes=min(maxNumberofVMs, pendingTaskSamples);’;
C:\> Enable-AzureBatchAutoScale -Id "RiskGridPool" -AutoScaleFormula $Formula -BatchContext $Context
Масштабирование также можно выполнить с помощью Azure CLI с az batch pool resize помощью команды и портал Azure.
Хранение и период удержания данных
После приема и обработки данных вычислительным узлом полученные выходные данные можно хранить в базе данных. Выходные данные можно дополнительно обрабатывать и анализировать или преобразовывать при приеме перед хранением, чтобы обеспечить надлежащие форматы для последующей обработки. Microsoft Azure предлагает несколько параметров хранилища. Выбор технологии хранилища данных (см. здесь) зависит главным образом от анализа и создания отчетов в процессах последующей обработки.
При использовании гибридной сети, целевое хранилище данных может оставаться локальным. При использовании пакетной службы в гибридной сети, вычислительные узлы могут записывать данные обратно в локальное хранилище данных, не используя место хранение на основе Azure. Рабочие роли также могут записываться в хранилище файлов Azure, которое может быть подключено как диск на локальном компьютере. Эта настройка позволяет легко получить доступ к любому процессу, который работает с файлами в локальной среде.
Мониторинг и ведение журналов
Чтобы оптимизировать последующие запуски из пакетного задания, данные необходимо записать для облегчения идентификации областей оптимизации. Например, если рабочие роли выполняются почти с мощностью ЦП, чтобы избежать ограниченного возможностями ЦП и ускорить завершение задания, необходимо добавить ядра для вычислительных узлов. Каждое выполнение приложения в пакетном задании имеет свои собственные характеристики и оптимизации, внесенные в виртуальные машины в пакетной службе, могут отличаться. Для задач с большим объемом памяти можно выделить больше памяти, настроив компьютеры по-другому в следующем запуске.
Ведение журнала можно выполнить с помощью вычислительных узлов и головного приложения сетки или задания с помощью ведения журнала диагностики пакетной службы. Сведения ведения журнала о производительности выполнений пакетной службы можно настроить для определения областей для улучшения повышения производительности и более быстрого выполнения задачи.
Мониторинг и ведение журнала пользовательской пакетной службы
Управляющее приложение и приложения вычислительного узла могут создать данные и хранить их для дальнейшего анализа. Для оптимизации пакетных заданий необходимы данные, включают в себя следующее:
- время начала и завершения задач;
- время существования вычислительного узла и выполнения задач;
- время существования вычислительного узла и не выполнения задач;
- общее время выполнения пакетного задания.
Ведение журнала диагностики пакетной службы
Существует альтернатива использованию приложений контроллера и вычислительных узлов для выдачи данных инструментирования. Пакетное диагностика ведение журнала может записывать много данных выполнения. Ведение журнала диагностики пакетной службы по умолчанию не включено и должно быть включено для учетной записи пакетной службы.
Ведение журналов диагностики пакетной службы обеспечивает значительное количество данных, помогающих при съемке и оптимизации пакетных запусков. Время начала и окончания заданий и задач, количество ядер, общее число узлов и многие другие метрики.
Для ведения журнала пакетной службы требуется назначение хранилища для журналов, созданных пакетной службой, таких как создание пула, выполнение заданий, выполнение задач и т. д. Помимо хранения событий журнала диагностики в учетной записи служба хранилища Azure, события журнала пакетной службы можно передавать в экземпляр Центры событий Azure. Затем события можно отправить в Azure Log Analytics.
С помощью этих данных можно оптимизировать основные вычисления и приложения головного узла. Это может снизить затраты из-за более быстрого отмены подготовки рабочих виртуальных машин, когда они больше не нужны, а не ожидая завершения выполнения пакетной службы.
Средства управления пакетной службой
Портал Azure предоставляет панель мониторинга пакетной службы, в котором отображаются сведения о выполнении заданий пакетной службы и даже использовании квоты учетной записи. Достаточно для многих приложений пакетного задания.
Помимо средств управления пакетной службой и визуализации, доступных в портал Azure, существует бесплатное средство с открытым исходным кодом, пакетная Обозреватель для управления пакетной службой. Это автономное клиентское средство для создания, отладки и мониторинга приложений пакетная служба Azure. Скачайте пакет установки для Mac, Linux или Windows.
Модели сети
Для анализа рисков часто требуется сотни, если не тысячи, документов, которые необходимо передать в процесс риска распределенные вычисления типа "решетка". Эти файлы часто расположены локально в хранилище файлов, сетевой папке или другом репозитории. При использовании виртуальных машин на основе Azure для доступа к этим файлам и их обработке часто полезно для локальной сети легко подключаться к сети Azure, поэтому доступ к файлам является простым и быстрым. Этот подход может даже означать, что для кода, выполняющего обработку на вычислительных узлах, не требуется никаких изменений кода.
Azure предлагает две модели для надежного и безопасного подключения текущих локальных систем в Azure, Microsoft Azure ExpressRoute и VPN-шлюзе. Эти системы предлагают безопасное надежное подключение, несмотря на то, что существуют различия в реализации, производительности и других атрибутах.
Главный узел распределенных вычислений типа "решетка" для риска может размещаться локально или выполнять задания через REST API или пакеты SDK для .NET и других языков.
Существуют другие способы использования моста между Azure и локальным ресурсам без гибридного сетевого решения. Дополнительная информация об этом приведена ниже.
ExpressRoute
ExpressRoute связывает локальную сеть или сеть центра обработки данных с Azure через частное подключение, которое упрощается партнером по подключению, например текущим поставщиком услуг Интернета. Это позволяет обеим сетям видеть друг друга как тот же экземпляр сети, обеспечивая простой доступ между сетями. Сетевая интеграция критическая в том случае, если вы хотите интегрировать существующие локальные системы с сетью Azure и ExpressRoute предлагает максимально возможную скорость подключения.
Дополнительные сведения о ценах для Azure ExpressRoute можно найти на этой странице.
VPN-шлюз
VPN-шлюз — еще один способ подключить вашу сеть к Azure. Недостатком этой модели является трафик, проходящий через Интернет. Подключение может быть менее устойчивым в результате, и скорость сети не может достичь скорости ExpressRoute, однако это не может быть барьером для сценария вычислений сетки риска, так как чтение файлов данных обычно является быстрой операцией.
Дополнительные сведения о ценах для VPN-шлюза можно найти на этой странице.
Варианты для сведений о подключении
Существует по сути две модели расширения сети в Azure, как показано на рис. 5.
- Виртуальный шлюз — сеть — сеть
- ExpressRoute. Поставщик Exchange или поставщик услуг Интернета
Рисунок 5. Подключение типа "сеть – сеть" и ExpressRoute
Интеграция "сеть — сеть" виртуального шлюза
VPN-шлюз подключения типа "сеть – сеть" устанавливает подключение локальной сети к виртуальной сети Azure. Это ликвидирует разрыв между сетями, делая их частью той же сети с двухстороннем доступом к ресурсам, серверам и артефактам. Это обеспечивает прямой доступ к файлам данных из Azure рабочей роли виртуальных машин выполняемых риск распределенных вычислений типа "решетка" для пакетного задания.
Интеграция ExpressRoute
Подключение ExpressRoute, которое содействует с поставщиком сети партнеров Azure предоставляет те же преимущества, что и подключение типа "сайт – сайт", но с более высокой скоростью и надежностью.
Дополнительные сведения о моделях подключения ExpressRoute.
Пакетная обработка без гибридной сети Azure
Другой сценарий пакетной службы отправляет все файлы данных в хранилище Azure для последующей обработки вычислительными машинами на базе Azure. Хранилище файлов и хранилище больших двоичных объектов отлично подходят для хранения данных рисков распределенных вычислений типа "решетка".
В этом случае контроллер задания и все вычислительные узлы находятся в Azure, как показано на рисунке 6. Наиболее вероятное назначение для обработанных данных находится в хранилище данных Azure, где готовится к дальнейшей обработке с помощью решений машинного обучения Azure или других систем. Этот дополнительный процесс не выходит в статью.
Рисунок 6. Передача пакетной службы для выполнения жизненного цикла
Ресурсы подключения к гибридной сети
В этом случае можно применить несколько конфигураций. Для решения и руководство по архитектуре о подключении к сети Azure см. статью Подключение локальной сети к Azure с помощью группы шаблонов и рекомендаций.
- Альтернативные варианты конфигурации VPN-шлюза см. в этой статье.
- Узнайте о моделях подключения ExpressRoute.
- Сведения о ценах на ExpressRoute см. здесь.
- Дополнительные сведения см. на странице Цены на Шлюз VPN.
Вопросы безопасности
Можно создать Виртуальная сеть (VNet) Azure и вычислительные узлы пула внутри нее. Это обеспечивает дополнительный уровень изоляции для выполнения пакетной службы и разрешает проверку подлинности с помощью идентификатора Microsoft Entra. Дополнительные сведения см. в разделе "Конфигурация сети пула".
Существует два способа проверки подлинности пакетного приложения с помощью идентификатора Microsoft Entra:
Встроенная аутентификация. Пакетное приложение, использующее учетные записи Microsoft Entra, может использовать учетную запись для получения ресурсов в хранилищах данных и других ресурсах.
Субъект-служба. Субъекты-службы Microsoft Entra определяют политику доступа и разрешения для пользователей и приложений. Субъект-служба обеспечивает аутентификацию для пользователей с помощью секретного ключа, привязанного к этому приложению. Это позволяет аутентификацию автоматического приложения с помощью секретного ключа. Субъект-служба определяет политику и разрешения приложения, чтобы представить приложение при получении доступа к ресурсам в среде выполнения. Дополнительные сведения см. здесь.
Дополнительные сведения о безопасности в пакетной обработке с помощью идентификатора Microsoft Entra см. в этой статье.
Пакетная служба также позволяет проверять подлинность с помощью ключа общего доступа. Служба аутентификации требует два значения заголовка для добавления HTTP-запроса, данных и авторизации. Дополнительные сведения о проверке подлинности ключа общего доступа см. здесь.
Оптимизация затрат
Плата за использование пакетная служба Azure не взимается. Вы платите только за использованные базовые ресурсы, такие как виртуальные машины, хранилище и сетевые ресурсы. Однако виртуальные машины вычислительного узла по-прежнему стоят денег при простое, поэтому рекомендуется отменить подготовку компьютеров, когда они больше не нужны. Это делается путем удаления пула, в котором они находятся.
При создании пула можно указать нужные типы вычислительных узлов, а также их количество. Ниже приведены два типа вычислительных узлов.
Выделенные вычислительные узлы зарезервированы для рабочих нагрузок. Они дороже, чем низкоприоритетные узлы, но они гарантированно никогда не будут упрещены.
Низкоприоритетные вычислительные узлы используют избыточные ресурсы в Azure для выполнения рабочих нагрузок пакетной службы. Они экономичнее (дешевле в час) по сравнению с выделенными узлами и выполняют рабочие нагрузки, требующие большого объема вычислительной мощности. Дополнительные сведения см. в статье Использование низкоприоритетных виртуальных машин в пакетной службе (предварительная версия).
Выделенные и низкоприоритетные узлы могут существовать в одном пуле.
Дополнительные сведения о ценах на низкоприоритетные и выделенные вычислительные узлы см. на странице цен на пакетную службу.
При использовании журнала ведения диагностики пакетной службы, данные в хранилище Azure оплачиваются. Это хранилище данных, такое как и любые другие данные, и цены зависит от объема хранимых данных диагностики.
Начало работы
Несмотря на наличие многих мест для начала работы со сложным доменом (например, пакетная обработка риска распределенных вычислений типа "решетка"), ниже приведены некоторые логические начиная, которые помогут лучше разобраться в технологии пакетной службы.
Документация по пакетная служба Azure является отличным местом для начала. Документация содержит примеры портала, ссылки на API и пошаговые руководства с примерами кода. Примеры приложений пакетной службы Azure доступны на сайте GitHub.
Ниже приведены некоторые руководства, которые помогут создать простое приложение для создания и выполнения пакетных вычислительных заданий. Ниже приведены параметры для создания приложения.
- Краткое руководство по выполнению первого пакетного задания Azure с помощью API для .NET
- Краткое руководство по выполнению первого пакетного задания с помощью API Python
- Приступая к работе с пакетом SDK для пакетной службы для Node.js
- Управление ресурсами пакетной службы с помощью командлетов PowerShell
- Управление ресурсами пакетной службы с помощью Azure CLI
Рассмотрите возможность запуска инициативы подтверждения концепции. Каким будет ваш подход для приема данных в Azure? Будет ли использовать гибридную сеть или передачу данных с помощью пакета SDK или интерфейса REST? Если вы рассматриваете гибридную сеть, рассмотрите возможность запуска пилотного проекта для этого.
Оцените размер заданий вычислений пакетной службы и выберите правильное решение для масштабирования. Формулы автомасштабирования позволяют выполнять сложные сценарии планирования, а более простые сценарии доступны с помощью портал Azure.
Компоненты
пакетная служба Azure предоставляет возможности для выполнения крупномасштабных параллельных заданий обработки в облаке.
Идентификатор Microsoft Entra — это мультитенантный, облачный каталог и служба управления удостоверениями, объединяющая основные службы каталогов, управление доступом к приложениям и защиту идентификации в одном решении.
Формулы автоматического масштабирования — это скрипты, переданные планировщику пакетной обработки для точного управления реакцией пакетной службы.
Журнал ведения диагностики пакетной службы — это возможность пакетной службы Azure, которая позволяет создание подробного журнала из выполнений и событий, создаваемых пакетной службой Azure. Журналы хранятся в службе хранилища Azure.
Пакетная Обозреватель — это автономное приложение для мониторинга пакетной службы и управления доступными Windows, macOS и Linux.
ExpressRoute — высокоскоростное и надежное гибридное сетевое решение для присоединения к локальным сетям и сетям Azure.
Azure VPN-шлюз — это гибридное сетевое решение с помощью Интернета для присоединения к локальным сетям и сетям Azure.
Заключение
Этот документ содержит обзор технических решений и рекомендаций при использовании пакетной службы Azure для рисков распределенных вычислений типа "решетка" для банковских операций. В статье было рассмотрено множество вопросов от определения пакетной службы Azure до параметров сети и даже затраты.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Основные авторы:
- Дэвид Старр | Архитектор основных решений
Следующие шаги
Чтобы изучать оценку рисков распределенных вычислений типа "решетка" пакетной службы Azure см. здесь — это хороший ресурс, для начала работы. В нем предоставлено пример руководств для обработки параллельных файлов, которые являются неотъемлемой частью риска распределенных вычислений типа "решетка". Руководства предоставляются с помощью портала Azure, Azure CLI, .NET и Python.
Документация по продукту:
- Что такое пакетная служба Azure?
- Что такое идентификатор Microsoft Entra?
- Что такое Azure ExpressRoute?
- Что такое VPN-шлюз?