Compartilhar via


Implantando aplicativos em nós do Azure em um cluster do Windows HPC

A partir do HPC Pack 2008 R2 com o Service Pack 1 (SP1), o HPC Pack inclui utilitários e mecanismos internos que ajudam os administradores de cluster a implantar aplicativos (como arquivos executáveis, serviços SOA, arquivos XLL e pastas de trabalho do Microsoft Excel habilitadas para cluster) para nós do Azure que são unidos a um cluster local em um cenário de "intermitência" do Azure. Por padrão, os nós do Azure não podem acessar recursos locais e pastas compartilhadas diretamente, portanto, os métodos que você usa para implantar aplicativos em nós do Azure diferem dos métodos usados para implantar aplicativos locais. Além disso, os nós do Azure adicionados a um cluster do Windows HPC são implantados e reprovisionados dinamicamente, portanto, os métodos recomendados para implantação de aplicativos ajudam a garantir que os aplicativos estejam automaticamente disponíveis em novas instâncias de nó do Azure.

Considerações sobre cargas de trabalho de aplicativo HPC para a intermitência do Azure

Antes de implantar aplicativos em nós do Azure, avalie se suas cargas de trabalho HPC existentes ou planejadas serão executadas ou dimensionadas com eficiência no Azure. As considerações detalhadas sobre migração, desenvolvimento e design para aplicativos HPC executados em um cenário de intermitência do Azure estão além do escopo deste tópico. Além disso, os recursos da plataforma do Azure estão em constante evolução. No entanto, a seguir estão as características atuais de uma intermitência bem-sucedida nas cargas de trabalho do Azure com o HPC Pack, especialmente para implantações em larga escala de nós do Azure:

  • cálculos de nó único altamente distribuídos Incluem muitos trabalhos soa (limpeza paramétrica) e determinadas arquiteturas orientadas a serviços. Outros tipos de trabalho, incluindo trabalhos de MPI (Interface de Passagem de Mensagem), podem ser executados em uma configuração de intermitência do Azure, mas podem exigir a seleção de uma tamanho de instância com uso intensivo de computação que dá suporte à rede RDMA do Azure. Para obter informações gerais sobre tipos de trabalho de HPC, consulte Noções básicas sobre trabalhos de computação paralela.

  • tempo de computação excede o tempo de movimentação de dados Determinadas cargas de trabalho de HPC exigem carregar grandes quantidades de dados no Azure para computação ou retornar grandes quantidades de dados que foram processados. Verifique se a movimentação de dados não é um gargalo no fluxo de trabalho do HPC.

  • acesso a dados baseados em arquivo aplicativos HPC existentes que acessam arquivos de dados locais podem ser facilmente migrados para execução no Azure acessando arquivos de dados carregados no armazenamento de blobs do Azure. Novos aplicativos HPC podem ser desenvolvidos para acessar a variedade de tipos de armazenamento no Azure. No entanto, dependendo da confidencialidade dos dados, dos requisitos legais, das considerações de custo e de outros fatores, talvez não seja possível armazenar dados do aplicativo no Azure.

  • padrão de carga de trabalho "Bursty" o cenário de intermitência do Azure é ideal para cargas de trabalho com uso intensivo de recursos que não são facilmente concluídas usando os recursos fixos de um cluster local. As cargas de trabalho podem incluir picos de computação irregulares, trabalhos agendados regularmente ou trabalhos pontuais.

Para obter mais informações sobre como executar aplicativos em nós do Azure, consulte Guidelines for Running HPC Applications on Azure Nodes.

Selecionando um método para implantar aplicativos e dados em nós do Azure

O método que você usa para implantar aplicativos e dados (em alguns casos) em nós do Azure depende do que é necessário para instalar seu aplicativo, conforme descrito na tabela a seguir.

Requisitos de instalação Método Disponibilidade
A instalação pode ser realizada copiando arquivos e quaisquer dependências, como DLLs ou arquivos de configuração para o nó. – Pacotes de administrador e arquivos de estágios para o armazenamento do Azure usando os comandos do hpcpack.
Consulte Usando hpcpack e hpcsync.
– O administrador implanta nós do Azure. Os pacotes são implantados automaticamente (copiados e extraídos) em novas instâncias de nó do Azure ou o administrador pode implantar manualmente se os nós já estiverem em execução.
Consulte intermitência para instâncias de trabalho do Azure com o Microsoft HPC Pack.
HPC Pack 2008 R2 com SP1
A instalação requer a execução silenciosa de um instalador ou requer etapas de configuração adicionais, como definir variáveis de ambiente ou criar exceções de firewall. – Pacotes de administrador e arquivos de estágios ou instaladores para o armazenamento do Azure usando os comandos do hpcpack.
Consulte Usando hpcpack e hpcsync.
– O administrador especifica um script de inicialização no modelo de nó do Azure para configurar o ambiente ou executar comandos de instalação.
Consulte usar um script de inicialização para nós do Azure.
– O administrador implanta nós do Azure. Os pacotes são implantados automaticamente em novas instâncias de nó do Azure e, em seguida, o script de inicialização é executado como parte do processo de provisionamento.
Consulte intermitência para instâncias de trabalho do Azure com o Microsoft HPC Pack.
HPC Pack 2008 R2 com SP2
A instalação e a distribuição de dados para nós do Azure podem ocorrer durante uma tarefa de preparação no momento em que o trabalho é executado. – O administrador usa uma ferramenta de armazenamento do Azure, como do AzCopy para carregar instaladores e arquivos de dados em um contêiner no armazenamento de blobs do Azure.
– Pacotes de administrador e estágios de arquivos ou instaladores adicionais para o armazenamento do Azure usando os comandos do hpcpack .
Consulte Usando hpcpack e hpcsync.
– O administrador especifica um script de inicialização no modelo de nó do Azure para configurar o ambiente ou executar comandos de instalação.
Consulte usar um script de inicialização para nós do Azure.
– O administrador implanta nós do Azure. Os pacotes são implantados automaticamente em novas instâncias de nó do Azure e, em seguida, o script de inicialização é executado como parte do processo de provisionamento.
Consulte intermitência para instâncias de trabalho do Azure com o Microsoft HPC Pack.
– O administrador cria um trabalho com uma tarefa de preparação de nó para executar etapas de instalação adicionais ou baixar dados de um contêiner de armazenamento de blobs do Azure.
Consulte Definir uma tarefa de preparação de nó –do Gerenciador de Trabalhos.
HPC Pack 2008 R2 com SP1
A instalação requer etapas que não são facilmente roteadas e os dados do aplicativo e do aplicativo podem ser acessados de uma unidade durável no Azure.

-
– O administrador usa ferramentas do Windows para criar um VHD (disco rígido virtual) e instala o aplicativo e todos os dados necessários do aplicativo no VHD.
– O administrador desanexa o VHD e usa o comando hpcpack upload para carregar o VHD como um blob de páginas no armazenamento do Azure.
Consulte Usando hpcpack e hpcsync.
– O administrador especifica o VHD do aplicativo que está no armazenamento do Azure ao configurar o modelo de nó do Azure.
Consulte montar um VHD de aplicativo em nós de trabalho do Azure.
– Opcionalmente, o administrador especifica um script de inicialização para configurações adicionais ou para configurar pastas compartilhadas em um ou mais nós na implantação.
Consulte usar um script de inicialização para nós do Azure.
– O administrador implanta nós do Azure. As instâncias de nó do Azure são criadas que montam o VHD do aplicativo, todos os pacotes no armazenamento são automaticamente implantados nos nós e, em seguida, o script de inicialização é executado como parte do processo de provisionamento.
Consulte intermitência para instâncias de trabalho do Azure com o Microsoft HPC Pack.
HPC Pack 2012

Usando hpcpack e hpcsync

Cada implantação de nó do Azure está associada a uma conta de armazenamento do Azure especificada no modelo de nó. Um administrador de cluster pode preparar arquivos (como aplicativos, serviços SOA, XLLs, pastas de trabalho do Excel habilitadas para cluster e utilitários) para a conta de armazenamento usando os comandos hpcpack. Você pode usar hpcpack criar para empacotar arquivos ou pastas em um formato compactado (.zip) que pode ser carregado no armazenamento do Azure. Cada aplicativo, serviço SOA ou XLL deve ser empacotado separadamente e o pacote deve incluir as dependências necessárias, como DLLs ou arquivos de configuração. Em seguida, você pode usar de upload do hpcpack para carregar o pacote na conta de armazenamento. Você pode executar os comandos hpcpack do nó principal ou em um computador que tenha os utilitários de cliente HPC instalados.

Todos os pacotes na conta de armazenamento são implantados automaticamente em novas instâncias de nó do Azure durante o processo de provisionamento. Isso acontece quando você implanta um conjunto de nós do Azure usando os utilitários de gerenciamento de HPC e se as instâncias do nó são reprovisionadas automaticamente pelo sistema do Windows Azure. O comando hpcsync é executado em cada nó do Azure e copia todos os pacotes do armazenamento para o nó e extrai os arquivos. Se você carregar pacotes no armazenamento depois que os nós do Azure forem iniciados, poderá implantar os pacotes executando o comando hpcsync manualmente em cada nó do Azure.

Observação

Se você criar vários modelos de nó do Azure que fazem referência à mesma conta de armazenamento, os mesmos arquivos em etapas serão implantados em todos os conjuntos de nós do Azure. Para implantar arquivos diferentes em diferentes conjuntos de nós, crie uma conta de armazenamento do Azure separada para cada modelo de nó do Azure.

O diagrama a seguir ilustra o fluxo de trabalho básico e os mecanismos para copiar aplicativos para nós do Azure:

Copiar aplicativos para nós do Azure no Windows HPC

Por padrão, hpcsync extrai arquivos para um local especificado pela variável de ambiente CCP_PACKAGE_ROOT. Essa variável é definida em nós do Azure durante o processo de provisionamento. Os arquivos extraídos são colocados em uma pasta determinada da seguinte maneira: %CCP_PACKAGE_ROOT%\<packageName>\<uploadTimeStamp>. Esse é o local esperado para serviços SOA, XLLs e pastas de trabalho do Excel. No entanto, isso não é conveniente para aplicativos que os usuários do cluster chamarão em suas linhas de comando. Para simplificar a estrutura de pastas para arquivos executáveis, você pode definir a propriedade de caminho relativo para o pacote quando carregá-la no armazenamento. hpcsync aplica o caminho relativo ao extrair os arquivos, de modo que o caminho seja determinado da seguinte maneira: %CCP_PACKAGE_ROOT%\<relativePath>. Os usuários podem especificar o caminho para seu aplicativo como no seguinte exemplo de um comando de envio de trabalho: job submit %CCP_PACKAGE_ROOT%\myRelativePath\myapp.exe

Veja a seguir considerações importantes sobre hpcsync e CCP_PACKAGE_ROOT:

  • Nos nós de trabalho do Azure, a pasta %CCP_PACKAGE_ROOT% é criada em uma partição de disco de 10 GB. Isso significa que todos os arquivos de aplicativo em uma instância de nó não podem exceder 10 GB. Se um aplicativo tiver arquivos de entrada e saída consideráveis, você poderá usar um script de inicialização para conceder permissões de usuário nas unidades C:\ para que os usuários possam gravar em todo o espaço disponível no nó.

  • Ao executar hpcsync manualmente, você pode substituir o local padrão (%CCP_PACKAGE_ROOT%). Por exemplo, você pode criar uma pasta em cada Nó do Azure e especificar esse local quando executar hpcsync. Todos os pacotes serão extraídos para essa pasta. No entanto, quaisquer novas instâncias de nó implantadas (ou reprovisionadas automaticamente) não incluirão essa pasta e os pacotes serão implantados automaticamente no local padrão. Além disso, os usuários do cluster só têm permissões de gravação em pastas no %CCP_PACKAGE_ROOT%. A menos que você modifique permissões de pasta nos nós do Azure, somente os administradores poderão executar aplicativos fora do %CCP_PACKAGE_ROOT%.

  • Quando hpcsync implanta um pacote, nenhum dos arquivos extraídos pode ter um comprimento de caminho completo maior que 256 caracteres. Os diretórios raiz em que os arquivos extraídos são temporariamente e, finalmente, colocados, podem levar até 136 caracteres, deixando 120 caracteres para o nome do arquivo, subdiretórios (se houver) e o relativePath (se especificado). Se o caminho dos arquivos extraídos exceder 256 caracteres, a implantação do pacote falhará.

O mecanismo de hpcsync é suficiente para implantar serviços SOA, arquivos XLL e aplicativos que podem ser instalados simplesmente copiando arquivos para um nó. Se você precisar executar um instalador para instalar um aplicativo ou se o aplicativo exigir etapas de configuração adicionais, como definir variáveis de ambiente, adicionar exceções de firewall, modificar permissões de pasta ou criar pastas, você poderá incluir um script de inicialização no modelo de nó. Esse script será executado durante o processo de provisionamento após hpcsync é executado e pode ser usado para configurar os nós e executar as etapas de instalação do aplicativo necessárias.

Como preparar arquivos de aplicativo para o armazenamento do Azure

Esta seção fornece informações sobre como empacotar aplicativos e stage-los para o armazenamento do Azure usando hpcpack. Os pacotes preparados são implantados automaticamente em novas instâncias de nó do Azure que você provisiona (ou que são reprovisionadas automaticamente pelo sistema do Azure).

Observação

Você deve ser um administrador de cluster ou pelo menos ter a ID da assinatura do Azure e a chave da conta de armazenamento para preparar arquivos para o armazenamento do Azure.

Requisitos

Se você estiver empacotando um serviço SOA:

  • O nome do pacote deve ser o nome do serviço SOA (ou seja, o nome de serviço especificado pelo cliente SOA no construtor SessionStartInfo). Por exemplo, serviceName.zip ou serviceName_serviceVersion.zip.

  • Você deve incluir a DLL de serviço, as DLLs dependentes e os arquivos de configuração de serviço no pacote.

  • O arquivo de configuração de serviço também deve ser implantado no nó principal. Todas as configurações são determinadas pela cópia local do arquivo de configuração.

  • Não especifique um caminho relativo ao carregar o pacote. Os serviços SOA devem ser descompactados para o local padrão.

Se você estiver empacotando um arquivo XLL:

  • O nome do pacote deve ser o nome do arquivo XLL. Por exemplo, XLLName.zip.

  • Se o XLL tiver dependências, coloque o XLL e os arquivos de suporte em uma pasta e empacote a pasta. O XLL deve estar no nível superior da pasta (não em uma subpasta).

  • Não especifique um caminho relativo ao carregar o pacote. AS XLLs devem ser desempacotadas para o local padrão.

Se você estiver empacotando uma pasta de trabalho do Excel:

  • O nome do pacote deve ser o nome da pasta de trabalho. Por exemplo, workbookName.zip.

  • Se a pasta de trabalho tiver dependências, coloque a pasta de trabalho e os arquivos de suporte em uma pasta e empacote a pasta. A pasta de trabalho deve estar no nível superior da pasta (não em uma subpasta).

  • Não especifique um caminho relativo ao carregar o pacote. As pastas de trabalho devem ser desempacotadas para o local padrão.

Se você estiver empacotando um arquivo executável (como um aplicativo MPI), instalador de aplicativo ou utilitário que você chamará de um script de inicialização:

  • Você deve incluir quaisquer DLLs ou arquivos dependentes no pacote.

  • Ao carregar o pacote, especifique a propriedade de caminho relativo.

Se você estiver empacotando um script de inicialização:

  • O nome do pacote deve ser o nome do script de inicialização. Por exemplo, startup.bat.zip.

  • Não especifique um caminho relativo ao carregar o pacote. O script de inicialização deve ser descompactado para o local padrão.

  • Se o script de inicialização chamar instaladores ou utilitários, certifique-se de empacotar e preparar os arquivos necessários separadamente.

Etapas

Como exemplos, os procedimentos a seguir ilustram como preparar vários tipos de arquivos de aplicativo para o armazenamento do Azure.

Observação

Você não precisa de um prompt de comando com privilégios elevados (executado como Administrador) para executar hpcpack criar. No entanto, de carregamento do hpcpack requer elevação. Para executar os procedimentos a seguir, execute os comandos em uma janela de prompt de comando com privilégios elevados.

Para empacotar e preparar um serviço SOA para o armazenamento do Azure
  1. Se o serviço SOA ainda não estiver registrado e implantado no cluster local, registre o serviço SOA colocando uma cópia do arquivo de configuração de serviço na pasta de registro de serviço no nó principal (normalmente é %CCP_HOME%\ServiceRegistration). Para obter informações detalhadas, consulte Implantar e Editar o Arquivo de Configuração de Serviço.

  2. Copie o arquivo de configuração de serviço, o assembly de serviço e as DLLs dependentes para uma pasta vazia. Por exemplo, copie os arquivos para uma pasta chamada C:\myFiles\myServiceFiles.

  3. Em um prompt de comando com privilégios elevados, execute hpcpack criar e especifique um nome para o pacote e a pasta que contém seus arquivos de serviço.

    Importante

    O nome do pacote deve ser o nome do serviço SOA (ou seja, o nome do serviço especificado pelo cliente SOA no construtor SessionStartInfo).

    Por exemplo, para empacotar o conteúdo de C:\myFiles\myServiceFiles como myServiceName.zip (e salvar o pacote em uma pasta chamada AzurePackages):

    hpcpack create C:AzurePackagesmyServiceName.zip C:myFilesmyServiceFiles

  4. Execute de carregamento do hpcpack para carregar o pacote no armazenamento do Azure usando o comando a seguir, em que myHeadNode é o nome do nó principal e myAzureTemplate é o nome do modelo usado para implantar os nós do Azure. Por exemplo:

    hpcpack upload C:\AzurePackages\myServiceName.zip /nodetemplate:myAzureNodeTemplate /scheduler:myHeadNode

Para empacotar e preparar um arquivo XLL ou pasta de trabalho do Excel para o armazenamento do Azure
  1. Se a XLL ou pasta de trabalho tiver dependências em DLLs ou outros arquivos, copie a XLL ou pasta de trabalho e suas dependências para uma pasta, como c:\myFiles\myExcelFiles.

  2. Em um prompt de comando com privilégios elevados, execute hpcpack criar para empacotar sua XLL ou pasta de trabalho. Especifique um nome para o pacote e especifique a XLL ou pasta de trabalho. O nome do pacote deve ser o nome do arquivo XLL ou da pasta de trabalho do Excel.

    Por exemplo, se sua XLL ou pasta de trabalho tiver dependências, empacote a pasta inteira (e salve o pacote em uma pasta chamada AzurePackages):

    hpcpack create C:\AzurePackages\myXLL.zip C:\myFiles\myExcelFiles

    Se sua XLL ou pasta de trabalho não tiver dependências, você poderá empacotá-la diretamente. Por exemplo, para empacotar C:\myFiles\myXLL.xll como myXLL.zip:

    hpcpack create C:\AzurePackages\myXLL.zip C:\myFiles\myXLL.xll

  3. Execute de carregamento do hpcpack para carregar o pacote no armazenamento do Azure usando o comando a seguir, em que myHeadNode é o nome do nó principal e myAzureTemplate é o nome do modelo usado para implantar os nós do Azure. Por exemplo:

    hpcpack upload C:\AzurePackages\myXLL.zip /nodetemplate:myAzureNodeTemplate /scheduler:myHeadNode

Para empacotar e preparar um arquivo executável para o armazenamento do Azure
  1. Copie o executável e quaisquer dependências ou DLLs para uma pasta, como C:\myFiles\myAppFiles.

  2. Em um prompt de comando com privilégios elevados, execute hpcpack criar para empacotar seus arquivos de aplicativo. Especifique um nome para o pacote e especifique a pasta que contém os arquivos do aplicativo.

    Por exemplo, para empacotar o conteúdo de c:\myFiles\myAppFiles como myApp.zip (e salvar o pacote em uma pasta chamada AzurePackages):

    hpcpack create c:\AzurePackages\myApp.zip c:\myFiles\myAppFiles

  3. Carregue o pacote no armazenamento do Azure usando o comando a seguir, em que myHeadNode é o nome do nó principal e myAzureTemplate é o nome do modelo que você usou para implantar os nós do Azure. Especifique um caminho relativo para os arquivos do aplicativo. Por exemplo:

    hpcpack upload c:\AzurePackages\myApp.zip /scheduler:myHeadNode /nodetemplate:myAzureTemplate /relativepath:myApp

Como implantar pacotes em etapas em nós do Azure

Os pacotes que são preparados para o armazenamento do Azure são implantados automaticamente em novas instâncias de nó. Você pode implantar manualmente pacotes – por exemplo, para verificar se você tem todas as dependências necessárias em um pacote antes de automatizar a implantação em todos os novos nós ou implantar pacotes em nós que já estão em execução. Você pode usar e hpcsync para implantar os arquivos da conta de armazenamento do Azure nos nós do Azure.

Por exemplo:

clusrun /nodegroup:AzureWorkerNodes hpcsync

Para ver uma lista de pastas ou arquivos que foram implantados nos nós do Azure, você pode executar o seguinte comando:

clusrun /nodegroup:AzureWorkerNodes dir %CCP_PACKAGE_ROOT% /s

Acessando arquivos de nós do Azure

Se o aplicativo HPC exigir acesso a arquivos, veja a seguir as opções para acessar arquivos dos aplicativos implantados nos nós do Azure.

Opção Pré-requisitos Observações
Unidade do Azure O administrador configura e monta um VHD de aplicativo em nós do Azure.

Consulte montar um VHD de aplicativo em nós de trabalho do Azure.
- A unidade é copiada e armazenada em cache localmente em cada nó
- A unidade pode ser gravada por apenas um nó de cada vez
Servidor de arquivos na Máquina Virtual do Azure O administrador configura uma instância de máquina virtual do Azure, anexa um disco de dados à máquina virtual, habilita a função servidor de arquivos e cria uma pasta de compartilhamento de arquivos.

Consulte Como configurar um servidor de arquivos de máquina virtual do Azure e usá-lo em trabalhos de computação do Windows HPC Server.
– O acesso por trabalhos aos recursos do servidor de arquivos requer acesso de usuário autenticado.
- Fornece compatibilidade de SMB para aplicativos existentes
– Fornece um máximo de 16 TB de dados por servidor
- Limita a largura de banda a 800 Mb/s
Espelhar arquivos locais para o armazenamento de blobs do Azure O administrador usa uma ferramenta de armazenamento do Azure, como do AzCopy para espelhar arquivos locais em um contêiner no armazenamento de blobs do Azure.
– O espelhamento de dados do ambiente local para o Azure adiciona sobrecarga.
Acessar o armazenamento de blobs do Azure diretamente O aplicativo é projetado para executar operações de acesso a dados diretamente nos blobs do Azure - Fornece a maior escalabilidade das opções disponíveis

Referências adicionais