Operando numa rede bloqueada
A aplicação CycleCloud e os nós de cluster podem funcionar em ambientes com acesso limitado à Internet, embora existam um número mínimo de portas TCP que devem permanecer abertas.
Instalar o Azure CycleCloud numa rede bloqueada
O CycleCloud VM deve ser capaz de se conectar a uma série de APIs Azure para orquestrar VMs de cluster e autenticar para O Diretório Ativo Azure. Uma vez que estes APIs utilizam HTTPS, o CycleCloud requer acesso HTTPS de saída a:
- management.azure.com (Gestão Azure ARM)
- login.microsoftonline.com (Azure AD)
- watson.telemetry.microsoft.com (Telemetria Azure)
- dc.applicationinsights.azure.com (Aplicação Azure Insights)
- dc.applicationinsights.microsoft.com (Aplicação Azure Insights)
- dc.services.visualstudio.com (Aplicação Azure Insights)
- ratecard.azure-api.net (Dados de Preços Azure)
A API de gestão está hospedada regionalmente, e os intervalos de endereços IP públicos podem ser encontrados aqui.
O Azure AD login faz parte dos intervalos de endereços APIs e IP comuns da Microsoft 365 para o serviço.
Os intervalos de endereço IP Azure Insights e Log Analytics podem ser consultados aqui.
O Azure CycleCloud deve poder aceder às contas do Azure Storage. A forma recomendada de fornecer acesso privado a este serviço e a qualquer outro serviço Azure suportado é através de Rede Virtual Service Endpoints.
Se utilizar grupos de segurança de rede ou o Azure Firewall limitar o acesso de saída aos domínios necessários, então é possível configurar o Azure Cyclecloud para encaminhar todos os pedidos através de um representante HTTPS. Ver: Utilização de um Web Proxy
Configurar um Grupo de Segurança da Rede Azure para o CicloCloud VM
Uma forma de limitar o acesso à Internet de saída a partir do CycleCloud VM sem configurar o Azure Firewall ou um representante HTTPS é configurar um rigoroso Grupo de Segurança da Rede Azure para a sub-rede do CycleCloud VM. A forma mais simples de o fazer é utilizar tags de serviço na sub-rede ou no VM level Network Security Group para permitir o acesso a azure de saída necessário.
Configure um ponto final de serviço de armazenamento para a sub-rede para permitir o acesso de CycleCloud a Azure Storage
Adicione a seguinte regra de saída NSG para negar o acesso de saída por padrão usando a Etiqueta de serviço de destino "Internet":
| Prioridade | Name | Porta | Protocolo | Origem | Destino | Ação |
|---|---|---|---|---|---|---|
| 4000 | BlockOutbound | Qualquer | Qualquer | Qualquer | Internet | Negar |
- Adicione as seguintes regras de saída NSG para permitir o acesso de saída aos serviços Azure necessários por marca de serviço de destino:
| Prioridade | Name | Porta | Protocolo | Origem | Destino | Ação |
|---|---|---|---|---|---|---|
| 100 | AllowAzureStorage | 443 | TCP | Qualquer | Armazenamento | Permitir |
| 101 | PermitirAtivadDirectório | 443 | TCP | Qualquer | AzureActiveDirectory | Permitir |
| 102 | AllowAzureMonitor | 443 | TCP | Qualquer | AzureMonitor | Permitir |
| 103 | AllowAzurerm | 443 | TCP | Qualquer | AzureResourceManager | Permitir |
Comunicações internas entre nós de cluster e CycleCloud
Estas portas precisam de estar abertas para permitir a comunicação entre os nós de cluster e o servidor CycleCloud:
| Name | Origem | Destino | Serviço | Protocolo | Intervalo de Portas |
|---|---|---|---|---|---|
| amqp_5672 | Nó de cluster | CycleCloud | AMQP | TCP | 5672 |
| https_9443 | Nó de cluster | CycleCloud | HTTPS | TCP | 9443 |
Lançamento de clusters Azure CycleCloud numa rede bloqueada
Nota
Correr nós de cluster numa sub-rede sem acesso à Internet de saída é totalmente suportado hoje em dia, mas é um tópico avançado que muitas vezes requer uma imagem personalizada ou personalização dos tipos e projetos de cluster CycleCloud predefinidos ou ambos.
Estamos a atualizar ativamente os tipos e projetos de cluster para eliminar a maior ou toda a obra. Mas, se encontrar falhas com o seu tipo de cluster ou projeto no seu ambiente bloqueado, por favor considere abrir um pedido de assistência de Apoio.
Executar VMs ou clusters Cyclecloud numa rede virtual ou sub-rede com acesso à Internet de saída geralmente requer o seguinte:
- O Azure Cyclecloud deve ser acessível a partir dos VMs do cluster para obter uma funcionalidade completa. Uma das seguintes opções:
- Os VMs do cluster devem ser capazes de ligar ao Azure Cyclecloud diretamente através de HTTPS e AMQP, ou
- A funcionalidade Cyclecloud ReturnProxy deve ser ativada no tempo de criação do cluster e o ciclocloud em si deve ser capaz de se conectar ao ReturnProxy VM via SSH
- Todos os pacotes de software exigidos pelo cluster devem ser:
- Pré-instalado numa imagem gerida personalizada para os VMs do cluster, ou
- Disponível num espelho de repositório de pacote acessível a partir dos VMs, ou
- Copiado para o VM do Azure Storage e instalado diretamente por um projeto Cyclecloud
- Todos os nós cluster devem poder aceder às contas de Armazenamento Azure. A forma recomendada de fornecer acesso privado a este serviço e a qualquer outro serviço Azure suportado é permitir um Rede Virtual Service Endpoint para armazenamento Azure.
Projeto Atualizações do GitHub
Cyclecloud irá descarregar projetos de cluster do GitHub durante a fase de orquestração "Staging". Este download ocorrerá após a instalação inicial, após a atualização do Cyclecloud, ou quando iniciar um conjunto de um determinado tipo pela primeira vez. Num ambiente bloqueado, o tráfego de saída HTTPS para github.com pode ser bloqueado. Neste caso, a criação de nóduras durante a fase de fase de fase de recursos de encenação falhará.
Se o acesso ao GitHub puder ser aberto temporariamente durante a criação do primeiro nó, o CycleCloud preparará os ficheiros locais para todos os nós subsequentes. Se o acesso temporário não for possível, os ficheiros necessários podem ser descarregados de outra máquina e copiados para o CycleCloud.
Primeiro determine qual o projeto e versão que o seu cluster necessitará, por exemplo, Slurm 2.5.0. É normalmente o número de versão mais alto da base de dados para um determinado projeto.
/opt/cycle_server/cycle_server execute 'select * from cloud.project where name == "slurm"'
AdType = "Cloud.Project"
Version = "2.5.0"
ProjectType = "scheduler"
Url = "https://github.com/Azure/cyclecloud-slurm/releases/2.5.0"
AutoUpgrade = false
Name = "slurm"
Esta versão do projeto e todas as dependências encontram-se na [etiqueta de lançamento] (https://github.com/Azure/cyclecloud-slurm/releases/tag/2.5.0). Todos os artefactos para uma libertação devem ser descarregados. Primeiro descarregue o artefacto de código e crie um diretório blobs para as dependências adicionais.
wget https://github.com/Azure/cyclecloud-slurm/archive/refs/tags/2.5.0.tar.gz
tar -xf 2.5.0.tar.gz
cd cyclecloud-slurm-2.5.0 && mkdir blobs
#... download all other release artifacts to the /blobs directory with wget ...
wget -P "blobs/" https://github.com/Azure/cyclecloud-slurm/releases/download/2.6.1/cyclecloud_api-8.1.0-py2.py3-none-any.whl
#... copy all the files to the Cyclecloud server
#... then on the Cyclecloud server:
cyclecloud project build
mkdir -p /opt/cycle_server/work/staging/projects/slurm/2.5.0
mkdir -p /opt/cycle_server/work/staging/projects/slurm/blobs
cp build/slurm/* /opt/cycle_server/work/staging/projects/slurm/2.5.0/
cp blobs/* /opt/cycle_server/work/staging/projects/slurm/blobs/
chown -R cycle_server:cycle_server /opt/cycle_server/work/staging
Uma vez que estes ficheiros tenham sido encenados localmente, o Cyclecloud irá detetá-los e não tentará descarregá-los do GitHub.