Предварительные требования для Azure HPC Cache

Перед созданием нового Azure HPC Cache убедитесь, что ваша среда соответствует этим требованиям.

подписка Azure

Рекомендуется использовать платную подписку.

Сетевая инфраструктура

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

• Выделенная подсеть для экземпляра Azure HPC Cache
• Поддержка DNS для доступа к хранилищу и другим ресурсам кэша
• Доступ из подсети к дополнительным службам инфраструктуры Microsoft Azure, включая серверы NTP и службу хранилища очередей Azure.

Подсеть кэша

Для Azure HPC Cache требуется выделенная подсеть с этими качествами:

• Подсеть должна иметь не менее 64 IP-адресов.
• Обмен данными внутри подсети должен быть неограниченным. Если вы используете группу безопасности сети для подсети кэша, убедитесь, что она разрешает все службы между внутренними IP-адресами.
• Подсеть не может размещать другие виртуальные машины, даже для связанных служб, таких как клиентские компьютеры.
• Если вы используете несколько экземпляров Azure HPC Cache, для каждой из них требуется собственная подсеть.

Рекомендуется создать новую подсеть для каждого кэша. Вы можете создать виртуальную сеть и подсеть в рамках создания кэша.

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

Доступ к DNS

Кэшу требуется DNS для доступа к ресурсам за пределами своей виртуальной сети. В зависимости от того, какие ресурсы вы используете, может потребоваться настроить настраиваемый DNS-сервер и настроить пересылку между этим сервером и серверами Azure DNS:

• Для доступа к конечным точкам хранилища BLOB-объектов Azure и другим внутренним ресурсам требуется DNS-сервер на основе Azure.
• Чтобы получить доступ к локальному хранилищу, необходимо настроить пользовательский DNS-сервер, который может разрешать имена узлов хранилища. Это необходимо сделать перед созданием кэша.

Если используется только хранилище BLOB-объектов, для кэша можно использовать dns-сервер, предоставленный Azure по умолчанию. Однако если вам нужен доступ к хранилищу или другим ресурсам за пределами Azure, необходимо создать пользовательский DNS-сервер и настроить его для пересылки любых запросов на разрешение, относящиеся к Azure, на dns-сервер Azure.

Чтобы использовать пользовательский DNS-сервер, перед созданием кэша необходимо выполнить следующие действия.

• Создайте виртуальную сеть, в которую будет размещен кэш Azure HPC.

• Создайте DNS-сервер.

• Добавьте DNS-сервер в виртуальную сеть кэша.

  Выполните следующие действия, чтобы добавить DNS-сервер в виртуальную сеть на портале Azure:

  1. Откройте виртуальную сеть на портале Azure.
  2. Выберите DNS-серверы в меню "Параметры" на боковой панели.
  3. Выбрать пользовательский
  4. Введите IP-адрес DNS-сервера в поле.

Простой DNS-сервер также можно использовать для балансировки нагрузки клиентских подключений между всеми доступными точками подключения кэша.

Дополнительные сведения о виртуальных сетях Azure и конфигурациях DNS-сервера см. в разделе "Разрешение имен" для ресурсов в виртуальных сетях Azure.

Доступ NTP

HpC Cache должен получить доступ к серверу NTP для регулярной работы. Если вы ограничиваете исходящий трафик из виртуальных сетей, убедитесь, что трафик разрешен по крайней мере одному NTP-серверу. Сервер по умолчанию time.windows.com, а кэш связывается с этим сервером через порт UDP 123.

Создайте правило в группе безопасности сети кэша, которая разрешает исходящий трафик на сервер NTP. Правило может просто разрешить весь исходящий трафик через порт UDP 123 или иметь дополнительные ограничения.

В этом примере явным образом открывается исходящий трафик к IP-адресу 168.61.215.74, который является адресом, используемым time.windows.com.

Убедитесь, что правило NTP имеет более высокий приоритет, чем любые правила, которые широко запрещают исходящий доступ.

Дополнительные советы по доступу NTP:

• Если у вас есть брандмауэры между кэшем HPC и сервером NTP, убедитесь, что эти брандмауэры также разрешают доступ NTP.

• Вы можете настроить сервер NTP, который использует hpC Cache на странице "Сеть ". Дополнительные сведения см. в статье "Настройка дополнительных параметров ".

Доступ к хранилищу очередей Azure

Кэш должен иметь безопасный доступ к службе хранилища очередей Azure из выделенной подсети. Azure HPC Cache использует службу очередей при обмене данными о конфигурации и состоянии.

Если кэш не может получить доступ к службе очередей, при создании кэша может появиться сообщение CacheConnectivityError.

Существует два способа предоставления доступа:

• Создайте конечную точку службы хранилища Azure в подсети кэша. Сведения о добавлении конечной точки службы Microsoft.Storage см. в статье "Добавление подсети виртуальной сети".

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

  Добавьте правила для разрешения доступа к этим портам:

  • TCP-порт 443 для безопасного трафика к любому узлу в домене queue.core.windows.net (*.queue.core.windows.net).

  • TCP-порт 80 — используется для проверки сертификата на стороне сервера. Иногда это называется проверкой списка отозванных сертификатов (CRL) и обменом по протоколу проверки статуса сертификата (OCSP). Все *.queue.core.windows.net используют один и тот же сертификат и таким образом те же серверы CRL/OCSP. Имя узла хранится в SSL-сертификате на стороне сервера.

  Дополнительные сведения см. в советах по правилу безопасности в NTP-доступе .

  Эта команда содержит список серверов CRL и OCSP, которым требуется разрешить доступ. Эти серверы должны быть разрешаемыми DNS и доступны через порт 80 из подсети кэша.

  
  openssl s_client -connect azure.queue.core.windows.net:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' | openssl x509 -noout -text -in /dev/stdin |egrep -i crl\|ocsp|grep URI
  
  

  Выходные данные выглядят примерно так, и могут измениться, если ssl-сертификат обновляется:

  OCSP - URI:http://ocsp.msocsp.com
  CRL - URI:http://mscrl.microsoft.com/pki/mscorp/crl/Microsoft%20RSA%20TLS%20CA%2002.crl
  CRL - URI:http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20RSA%20TLS%20CA%2002.crl
  

Вы можете проверить подключение подсети с помощью этой команды из тестовой виртуальной машины в подсети:

openssl s_client -connect azure.queue.core.windows.net:443 -status 2>&1 < /dev/null |grep "OCSP Response Status"

Успешное подключение дает следующий ответ:

OCSP Response Status: successful (0x0)

Доступ к серверу событий

Azure HPC Cache использует конечные точки сервера событий Azure для мониторинга работоспособности кэша и отправки диагностических сведений.

Убедитесь, что кэш может безопасно обращаться к узлам в домене events.data.microsoft.com . То есть откройте TCP-порт 443 для трафика *.events.data.microsoft.com.

Разрешения

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

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

• При использовании хранилища Blob Azure HPC Cache требуется авторизация для доступа к учетной записи хранения. Используйте управление доступом на основе ролей Azure (Azure RBAC), чтобы предоставить кэшу доступ к хранилищу объектов BLOB. Требуются две роли: участник учетной записи хранения и участник данных BLOB-объектов хранилища.

  Следуйте инструкциям в разделе "Добавление целевых объектов хранилища" , чтобы добавить роли.

Инфраструктура хранилища

Кэш поддерживает контейнеры BLOB-объектов Azure, экспорт данных с устройств хранения NFS и контейнеры BLOB-объектов Azure Data Lake Storage, подключенных через NFS. Добавьте целевые объекты хранилища после создания кэша.

Каждый тип хранилища имеет определенные предварительные требования.

Требования к Blob-хранилищу

Если вы хотите использовать хранилище BLOB-объектов Azure с кэшем, вам нужна совместимая учетная запись хранения и пустой контейнер BLOB-объектов или контейнер, заполненный форматированными данными Azure HPC Cache, как описано в разделе "Перемещение данных в хранилище BLOB-объектов Azure".

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

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

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

Прочитайте «Работа с частными конечными точками», чтобы узнать рекомендации по использованию частных конечных точек с целями хранения HPC Cache.

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

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

Требования к хранилищу NFS

Если используется система хранения NFS (например, локальная система NAS), убедитесь, что она соответствует этим требованиям. Для проверки этих параметров может потребоваться работать с администраторами сети или диспетчерами брандмауэров для системы хранилища (или центра обработки данных).

Дополнительные сведения включены в сведения об устранении неполадок с конфигурацией NAS и целевыми объектами хранилища NFS.

• Сетевое подключение. Для azure HPC Cache требуется доступ к сети с высокой пропускной способностью между подсетью кэша и центром обработки данных системы NFS. Рекомендуется использовать ExpressRoute или аналогичный доступ. При использовании VPN может потребоваться настроить его для ограничения TCP MSS до 1350, чтобы убедиться, что большие пакеты не блокируются. Дополнительные сведения об устранении неполадок с параметрами VPN см. в ограничениях размера VPN-пакетов .

• Доступ к портам: кэшу требуется доступ к определенным портам TCP/UDP в системе хранения. Разные типы хранилища имеют разные требования к порту.

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

  • Выполните команду rpcinfo на системе хранения, чтобы проверить необходимые порты. Следующая команда содержит список портов и форматирует соответствующие результаты в таблице. (Используйте IP-адрес системы вместо <термина storage_IP> .)

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

    rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t
    

  Убедитесь, что все порты, возвращаемые rpcinfo запросом, разрешают неограниченный трафик из подсети Azure HPC Cache.

  • Если вы не можете использовать rpcinfo команду, убедитесь, что эти часто используемые порты разрешают входящий и исходящий трафик:

    Протокол	Порт	Услуга
    TCP/UDP	111	rpcbind
    TCP/UDP	2049	NFS
    TCP/UDP	4045	nlockmgr
    TCP/UDP	4046	подключение
    TCP/UDP	4047	статус

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

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

• Внутреннее хранилище NFS должно быть совместимой аппаратной и программной платформой. Хранилище должно поддерживать NFS версии 3 (NFSv3). Свяжитесь с командой Azure HPC Cache для получения подробностей.

Требования к хранилищу подключенных к NFS BLOB-объектов (ADLS-NFS)

Azure HPC Cache также может использовать контейнер блоб-объектов, подключенный по протоколу NFS в качестве целевого объекта хранилища.

Дополнительные сведения об этой функции см. в поддержке протокола NFS 3.0 в хранилище BLOB-объектов Azure.

Требования к учетной записи различаются для целевого объекта хранения объектов BLOB ADLS-NFS и для стандартного целевого объекта хранения объектов BLOB. Следуйте инструкциям в разделе «Монтирование хранилища Blob с использованием протокола NFS 3.0», чтобы создать и настроить учетную запись хранения с поддержкой NFS.

Это общий обзор шагов. Эти шаги могут измениться, поэтому всегда обращайтесь к инструкциям ADLS-NFS для получения текущей информации.

1. Убедитесь, что необходимые функции доступны в регионах, где планируется работать.

2. Включите функцию протокола NFS для подписки. Перед созданием учетной записи хранения сделайте это.

3. Создайте безопасную виртуальную сеть для учетной записи хранения. Для учетной записи хранения с поддержкой NFS и для Azure HPC Cache следует использовать ту же виртуальную сеть. (Не используйте ту же подсеть, что и кэш.)

4. Создайте учетную запись хранения.

   • Вместо использования параметров учетной записи хранения для стандартной учетной записи хранения BLOB-объектов следуйте инструкциям в документе. Тип поддерживаемой учетной записи хранения может отличаться в зависимости от региона Azure.

   • В разделе "Сеть" выберите частную конечную точку в созданной безопасной виртуальной сети (рекомендуется) или выберите общедоступную конечную точку с ограниченным доступом из безопасной виртуальной сети.

     Прочитайте «Работа с частными конечными точками», чтобы узнать рекомендации по использованию частных конечных точек с целями хранения HPC Cache.

   • Не забудьте завершить раздел "Дополнительно", где вы включите доступ к NFS.

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

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

Узнайте больше об использовании целевых объектов хранилища ADLS-NFS с Azure HPC Cache в использовании хранилища BLOB-объектов, подключенного к NFS, с Azure HPC Cache.

Работа с частными конечными точками

Служба хранилища Azure поддерживает частные конечные точки для обеспечения безопасного доступа к данным. Частные конечные точки можно использовать с объектами BLOB в Azure или с объектами блоб-хранилища, подключенными через NFS.

Подробнее о частных конечных точках

Частная конечная точка предоставляет определенный IP-адрес, который hpC Cache использует для взаимодействия с внутренней системой хранения. Если этот IP-адрес изменяется, кэш не может автоматически повторно установить подключение к хранилищу.

Если необходимо изменить конфигурацию частной конечной точки, выполните следующую процедуру, чтобы избежать проблем с взаимодействием между хранилищем и HPC Cache:

1. Приостановка целевого объекта хранилища (или всех целевых объектов хранилища, использующих эту частную конечную точку).
2. Внесите изменения в частную конечную точку и сохраните эти изменения.
3. Поместите целевой объект хранилища обратно в службу с помощью команды "резюме".
4. Обновите параметр DNS целевого объекта хранилища.

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

Настройка доступа к Azure CLI (необязательно)

Если вы хотите создать или управлять Azure HPC Cache из Azure CLI, необходимо установить Azure CLI и расширение hpc-cache. Следуйте инструкциям из руководства по настройке Azure CLI для Azure HPC Cache.

Дальнейшие действия

• Создание экземпляра Azure HPC Cache на портале Azure