As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
SageMaker HyperPod melhores práticas de configuração do ciclo de vida
SageMaker HyperPod oferece sempre clusters de up-and-running computação, que são altamente personalizáveis, pois você pode escrever scripts de ciclo de vida para informar SageMaker HyperPod como configurar os recursos do cluster. Os tópicos a seguir são as melhores práticas para preparar scripts de ciclo de vida para configurar SageMaker HyperPod clusters com ferramentas de gerenciamento de carga de trabalho de código aberto.
Prepare scripts de ciclo de vida para configurar o Slurm on SageMaker HyperPod
Os tópicos a seguir discutem como preparar scripts de ciclo de vida para configurar o Slurm
Tópicos
- Visão geral de alto nível
- Comece com scripts básicos de ciclo de vida fornecidos por HyperPod
- Quais configurações específicas HyperPod gerenciam nos arquivos de configuração do Slurm
- Monte o Amazon FSx for Lustre em seu cluster HyperPod
- Valide os arquivos JSON de configuração antes de criar um cluster Slurm no HyperPod
- Valide o tempo de execução antes de executar cargas de trabalho de produção em um cluster Slurm no HyperPod
- Desenvolva scripts de ciclo de vida interativamente em um nó de cluster
- Atualize um cluster com scripts de ciclo de vida novos ou atualizados
- Considerações
Visão geral de alto nível
O procedimento a seguir é o fluxo principal de provisionamento de um HyperPod cluster e sua configuração com o Slurm. As etapas são colocadas na ordem de uma abordagem de baixo para cima.
-
Planeje como você deseja criar nós do Slurm em um HyperPod cluster. Por exemplo, se você quiser configurar dois nós do Slurm, precisará configurar dois grupos de instâncias em um HyperPod cluster.
-
Prepare um
provisioning_parameters.json
arquivo, que é umFormulário de configuração para provisionamento de nós do Slurm em HyperPod.provisioning_parameters.json
deve conter informações de configuração do nó Slurm a serem provisionadas no cluster. HyperPod Isso deve refletir o design dos nós do Slurm da Etapa 1. -
Prepare um conjunto de scripts de ciclo de vida para configurar o Slurm on HyperPod para instalar pacotes de software e configurar um ambiente no cluster para seu caso de uso. Você deve estruturar os scripts de ciclo de vida para serem executados coletivamente em um script Python central (
lifecycle_script.py
) e escrever um script de shell de ponto de entrada ()on_create.sh
para executar o script Python. O script de shell do ponto de entrada é o que você precisa fornecer para uma solicitação de criação de HyperPod cluster posteriormente na Etapa 5.Além disso, observe que você deve escrever os scripts para esperar
resource_config.json
que sejam gerados HyperPod durante a criação do cluster.resource_config.json
contém informações de recursos do HyperPod cluster, como endereços IP, tipos de instância eARNs, e é o que você precisa usar para configurar o Slurm. -
Reúna todos os arquivos das etapas anteriores em uma pasta.
└── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py
-
Faça upload de todos os arquivos em um bucket do S3. Copie e mantenha o caminho do bucket do S3. Observe que você deve criar um caminho de bucket do S3 começando com
sagemaker-
porque você precisa escolher um com IAMpapel para SageMaker HyperPod anexadoAWS política gerenciada: AmazonSageMakerClusterInstanceRolePolicy, que só permite caminhos de bucket do Amazon S3 começando com o prefixo.sagemaker-
O comando a seguir é um exemplo de comando para carregar todos os arquivos em um bucket do Amazon S3.aws s3 cp --recursive
./lifecycle_files
s3://sagemaker-hyperpod-lifecycle/src
-
Prepare uma solicitação de criação de HyperPod cluster.
-
Opção 1: Se você usar o AWS CLI, escreva uma solicitação de criação de cluster em JSON format (
create_cluster.json
) seguindo as instruções emCrie um novo cluster. -
Opção 2: Se você usa a interface do usuário do SageMaker console, preencha o formulário Criar uma solicitação de cluster na interface do usuário do HyperPod console seguindo as instruções emCrie um SageMaker HyperPod cluster.
Nesse estágio, certifique-se de criar grupos de instâncias na mesma estrutura planejada nas etapas 1 e 2. Além disso, certifique-se de especificar o bucket do S3 da Etapa 5 nos formulários de solicitação.
-
-
Envie a solicitação de criação do cluster. HyperPod provisiona um cluster com base na solicitação e, em seguida, cria um
resource_config.json
arquivo nas instâncias do HyperPod cluster e configura o Slurm no cluster que executa os scripts de ciclo de vida.
A seção a seguir explica e detalha detalhadamente como organizar arquivos de configuração e scripts de ciclo de vida para que funcionem adequadamente durante HyperPod a criação do cluster.
Comece com scripts básicos de ciclo de vida fornecidos por HyperPod
Esta seção mostra cada componente do fluxo básico de configuração do Slurm on HyperPod em uma abordagem de cima para baixo. Ele começa com a preparação de uma solicitação de criação de HyperPod cluster para executar o CreateCluster
API e se aprofunda na estrutura hierárquica até os scripts de ciclo de vida. Use os exemplos de scripts de ciclo de vida fornecidos no repositório do Awsome Distributed Training
git clone https://github.com/aws-samples/awsome-distributed-training/
Os scripts básicos do ciclo de vida para configurar um cluster Slurm estão disponíveis em SageMaker HyperPod . 1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
cd awsome-distributed-training/1.architectures/5.sagemaker_hyperpods/LifecycleScripts/base-config
O fluxograma a seguir mostra uma visão geral detalhada de como você deve criar os scripts básicos do ciclo de vida. As descrições abaixo do diagrama e do guia de procedimentos explicam como eles funcionam durante a HyperPod CreateCluster
API chamada.
Figura: Um fluxograma detalhado da criação do HyperPod cluster e da estrutura dos scripts do ciclo de vida. (1) As setas tracejadas são direcionadas para onde as caixas são “chamadas” e mostram o fluxo dos arquivos de configuração e a preparação dos scripts do ciclo de vida. Tudo começa com a preparação provisioning_parameters.json
e os scripts do ciclo de vida. Eles são então codificados lifecycle_script.py
para uma execução coletiva em ordem. E a execução do lifecycle_script.py
script é feita pelo script on_create.sh
shell, que deve ser executado no terminal da HyperPod instância. (2) As setas sólidas mostram o fluxo principal de criação do HyperPod cluster e como as caixas são “chamadas para” ou “enviadas para”. on_create.sh
é necessário para a solicitação de criação de cluster, no formulário Criar uma solicitação de cluster create_cluster.json
ou no formulário Criar uma solicitação de cluster na interface do console. Depois de enviar a solicitação, HyperPod executa o CreateCluster
API com base nas informações de configuração fornecidas da solicitação e nos scripts do ciclo de vida. (3) A seta pontilhada indica que a HyperPod plataforma cria resource_config.json
nas instâncias do cluster durante o provisionamento de recursos do cluster. resource_config.json
contém informações sobre os recursos do HyperPod cluster, como o clusterARN, os tipos de instância e os endereços IP. É importante observar que você deve preparar os scripts de ciclo de vida para esperar o resource_config.json
arquivo durante a criação do cluster. Para obter mais informações, consulte o guia de procedimentos abaixo.
O guia de procedimentos a seguir explica o que acontece durante a criação HyperPod do cluster e como os scripts básicos do ciclo de vida são projetados.
-
create_cluster.json
— Para enviar uma solicitação de criação de HyperPod cluster, você prepara um arquivo deCreateCluster
solicitação em JSON formato. Neste exemplo de melhores práticas, presumimos que o arquivo de solicitação tenha um nomecreate_cluster.json
. Escrevacreate_cluster.json
para provisionar um HyperPod cluster com grupos de instâncias. A melhor prática é adicionar o mesmo número de grupos de instâncias que o número de nós do Slurm que você planeja configurar no HyperPod cluster. Certifique-se de dar nomes distintos aos grupos de instâncias que você atribuirá aos nós do Slurm que você planeja configurar.Além disso, é necessário especificar um caminho de bucket do S3 para armazenar todo o conjunto de arquivos de configuração e scripts de ciclo de vida no nome do campo
InstanceGroups.LifeCycleConfig.SourceS3Uri
no formulário deCreateCluster
solicitação e especificar o nome do arquivo de um script de shell de ponto de entrada (suponha que ele seja nomeado) para.on_create.sh
InstanceGroups.LifeCycleConfig.OnCreate
nota
Se você estiver usando o formulário de envio Criar um cluster na interface do usuário do HyperPod console, o console gerencia o preenchimento e o envio da
CreateCluster
solicitação em seu nome e a executaCreateCluster
API no back-end. Nesse caso, você não precisa criarcreate_cluster.json
; em vez disso, certifique-se de especificar as informações corretas de configuração do cluster no formulário de envio Criar um cluster. -
on_create.sh
— Para cada grupo de instâncias, você precisa fornecer um script de shell de ponto de entrada, executar comandoson_create.sh
, executar scripts para instalar pacotes de software e configurar o ambiente de HyperPod cluster com o Slurm. As duas coisas que você precisa preparar são umaprovisioning_parameters.json
exigência HyperPod para configurar o Slurm e um conjunto de scripts de ciclo de vida para instalar pacotes de software. Esse script deve ser escrito para localizar e executar os seguintes arquivos, conforme mostrado no script de amostra emon_create.sh
. nota
Certifique-se de carregar todo o conjunto de scripts de ciclo de vida no local do S3 especificado.
create_cluster.json
Você também deve colocar o seuprovisioning_parameters.json
no mesmo local.-
provisioning_parameters.json
— Este é umFormulário de configuração para provisionamento de nós do Slurm em HyperPod. Oon_create.sh
script encontra esse JSON arquivo e define a variável de ambiente para identificar o caminho até ele. Por meio desse JSON arquivo, você pode configurar os nós do Slurm e as opções de armazenamento, como o Amazon FSx for Lustre for Slurm, com os quais se comunicar. Emprovisioning_parameters.json
, certifique-se de atribuir os grupos de instâncias do HyperPod cluster usando os nomes especificados noscreate_cluster.json
nós do Slurm de forma adequada, com base em como você planeja configurá-los.O diagrama a seguir mostra um exemplo de como os dois arquivos de JSON configuração
provisioning_parameters.json
devem sercreate_cluster.json
gravados para atribuir grupos de HyperPod instâncias aos nós do Slurm. Neste exemplo, assumimos um caso de configuração de três nós do Slurm: nó controlador (gerenciamento), nó de login (que é opcional) e nó de computação (trabalhador).dica
Para ajudá-lo a validar esses dois JSON arquivos, a equipe de HyperPod serviço fornece um script de validação,
validate-config.py
. Para saber mais, consulte Valide os arquivos JSON de configuração antes de criar um cluster Slurm no HyperPod. Figura: Comparação direta entre
create_cluster.json
a criação HyperPod do cluster e a configuraçãoprovisiong_params.json
do Slurm. O número de grupos de instâncias emcreate_cluster.json
deve corresponder ao número de nós que você deseja configurar como nós do Slurm. No caso do exemplo na figura, três nós do Slurm serão configurados em um HyperPod cluster de três grupos de instâncias. Você deve atribuir os grupos de instâncias do HyperPod cluster aos nós do Slurm especificando os nomes dos grupos de instâncias adequadamente. -
resource_config.json
— Durante a criação do cluster, olifecycle_script.py
script é escrito para esperar umresource_config.json
arquivo do HyperPod. Esse arquivo contém informações sobre o cluster, como tipos de instância e endereços IP.Quando você executa o
CreateCluster
API, HyperPod cria um arquivo de configuração de recursos/opt/ml/config/resource_config.json
com base nocreate_cluster.json
arquivo. O caminho do arquivo é salvo na variável de ambiente chamadaSAGEMAKER_RESOURCE_CONFIG_PATH
.Importante
O
resource_config.json
arquivo é gerado automaticamente pela HyperPod plataforma e você NOT PRECISA criá-lo. O código a seguir é para mostrar um exemplo doresource_config.json
que seria criado a partir da criação do cluster com basecreate_cluster.json
na etapa anterior e para ajudar você a entender o que acontece no back-end e comoresource_config.json
seria a aparência de uma geração automática.{ "ClusterConfig": { "ClusterArn": "arn:aws:sagemaker:us-west-2:111122223333:cluster/abcde01234yz", "ClusterName": "your-hyperpod-cluster" }, "InstanceGroups": [ { "Name": "controller-machine", "InstanceType": "ml.c5.xlarge", "Instances": [ { "InstanceName": "controller-machine-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] }, { "Name": "login-group", "InstanceType": "ml.m5.xlarge", "Instances": [ { "InstanceName": "login-group-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] }, { "Name": "compute-nodes", "InstanceType": "ml.trn1.32xlarge", "Instances": [ { "InstanceName": "compute-nodes-1", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-2", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-3", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" }, { "InstanceName": "compute-nodes-4", "AgentIpAddress": "111.222.333.444", "CustomerIpAddress": "111.222.333.444", "InstanceId": "i-12345abcedfg67890" } ] } ] }
-
lifecycle_script.py
— Esse é o script principal do Python que executa coletivamente scripts de ciclo de vida configurando o Slurm no cluster enquanto está sendo provisionado. HyperPod Esse script lêprovisioning_parameters.json
eresource_config.json
recebe os caminhos especificados ou identificadoson_create.sh
, passa as informações relevantes para cada script de ciclo de vida e, em seguida, executa os scripts de ciclo de vida em ordem.Os scripts de ciclo de vida são um conjunto de scripts que você tem total flexibilidade para personalizar para instalar pacotes de software e definir as configurações necessárias ou personalizadas durante a criação do cluster, como configurar o Slurm, criar usuários, instalar o Conda ou o Docker. O
lifecycle_script.py
script de amostra está preparado para executar outros scripts básicos de ciclo de vida no repositório, como iniciar o Slurm deamons ( start_slurm.sh
), montar o FSx Amazon for Lustre () e configurar a contabilidade ( mount_fsx.sh
) e a contabilidade () do MariaDB. setup_mariadb_accounting.sh
RDSsetup_rds_accounting.sh
Você também pode adicionar mais scripts, empacotá-los no mesmo diretório e adicionar linhas de código lifecycle_script.py
para permitir a HyperPod execução dos scripts. Para obter mais informações sobre os scripts de ciclo de vida básicos, consulte também 3.1 Scripts de ciclo de vida no repositório Awsome DistributedTraining. GitHub Além das configurações padrão, mais scripts para instalar o software a seguir estão disponíveis na
utils
pasta. O lifecycle_script.py
arquivo já está preparado para incluir linhas de código para executar os scripts de instalação, portanto, consulte os itens a seguir para pesquisar essas linhas e descomentar para ativá-las.-
As linhas de código a seguir são para instalar o Docker
, o Enroot e o Pyxis. Esses pacotes são necessários para executar contêineres Docker em um cluster Slurm. Para ativar essa etapa de instalação, defina o
enable_docker_enroot_pyxis
parâmetro comoTrue
noconfig.py
arquivo. # Install Docker/Enroot/Pyxis if Config.enable_docker_enroot_pyxis: ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_enroot_pyxis.sh").run(node_type)
-
Você pode integrar seu HyperPod cluster ao Amazon Managed Service for Prometheus e ao Amazon Managed Grafana para exportar métricas HyperPod sobre o cluster e os nós do cluster para os painéis do Amazon Managed Grafana. Para exportar métricas e usar o painel Slurm, o painel NVIDIA
DCGMExporter e o painel Metrics no Amazon Managed Grafana, você precisa instalar o EFA exportador Slurm para Prometheus, o exportador e o exportador de nós. NVIDIA DCGM EFA Para obter mais informações sobre como instalar os pacotes do exportador e usar os painéis do Grafana em um espaço de trabalho do Amazon Managed Grafana, consulte. Monitore os recursos SageMaker HyperPod do cluster Para ativar essa etapa de instalação, defina o
enable_observability
parâmetro comoTrue
noconfig.py
arquivo. # Install metric exporting software and Prometheus for observability if Config.enable_observability: if node_type == SlurmNodeType.COMPUTE_NODE: ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_dcgm_exporter.sh").run() ExecuteBashScript("./utils/install_efa_node_exporter.sh").run() if node_type == SlurmNodeType.HEAD_NODE: wait_for_scontrol() ExecuteBashScript("./utils/install_docker.sh").run() ExecuteBashScript("./utils/install_slurm_exporter.sh").run() ExecuteBashScript("./utils/install_prometheus.sh").run()
-
-
-
Certifique-se de carregar todos os arquivos e scripts de configuração da Etapa 2 para o bucket do S3 que você fornece na
CreateCluster
solicitação na Etapa 1. Por exemplo, suponha que vocêcreate_cluster.json
tenha o seguinte."LifeCycleConfig": { "SourceS3URI": "
s3://sagemaker-hyperpod-lifecycle/src
", "OnCreate": "on_create.sh
" }Em seguida, você
"s3://sagemaker-hyperpod-lifecycle/src"
deve conteron_create.sh
,lifecycle_script.py
,provisioning_parameters.json
, e todos os outros scripts de configuração. Suponha que você tenha preparado os arquivos em uma pasta local da seguinte maneira.└── lifecycle_files // your local folder ├── provisioning_parameters.json ├── on_create.sh ├── lifecycle_script.py └── ... // more setup scrips to be fed into lifecycle_script.py
Para carregar os arquivos, use o comando S3 da seguinte maneira.
aws s3 cp --recursive
./lifecycle_scripts
s3://sagemaker-hyperpod-lifecycle/src
Quais configurações específicas HyperPod gerenciam nos arquivos de configuração do Slurm
Quando você cria um cluster do Slurm no HyperPod, o HyperPod agente configura os gres.conf
slurm.conf
/opt/slurm/etc/
para gerenciar o cluster do Slurm com base na solicitação de criação do cluster e nos scripts HyperPod do ciclo de vida. A lista a seguir mostra quais parâmetros específicos o HyperPod agente manipula e substitui.
Importante
É altamente recomendável que você não altere esses parâmetros gerenciados pelo HyperPod.
-
Em
slurm.conf
, HyperPod configura os seguintes parâmetros básicos: ClusterName
SlurmctldHost
PartitionName
,,NodeName
e.Além disso, para habilitar a Retoma automático funcionalidade, é HyperPod necessário definir
SchedulerParameters
os parâmetrosTaskPlugin
e da seguinte forma. O HyperPod agente configura esses dois parâmetros com os valores necessários por padrão.TaskPlugin=task/none SchedulerParameters=permit_job_expansion
-
Em
gres.conf
, HyperPod NodeName
gerencia quatro GPU nós.
Monte o Amazon FSx for Lustre em seu cluster HyperPod
Para montar um sistema de arquivos compartilhado Amazon FSx for Lustre em seu HyperPod cluster, configure o seguinte.
-
Use sua AmazonVPC.
-
Para que as instâncias de HyperPod cluster se comuniquem com vocêVPC, certifique-se de anexar permissões adicionais, conforme orientado em, IAMpapel para SageMaker HyperPod à IAM função de SageMaker HyperPod.
-
Em
create_cluster.json
, inclua as seguintes VPC informações."VpcConfig": { "SecurityGroupIds": [ "
string
" ], "Subnets": [ "string
" ] }Para obter mais dicas sobre como configurar a AmazonVPC, consulteConfigurando SageMaker HyperPod com a Amazon VPC.
-
-
Para concluir a configuração do Slurm com o Amazon FSx for Lustre, especifique o nome da Amazon FSx DNS e o nome da FSx montagem da Amazon
provisioning_parameters.json
conforme mostrado na figura na seção. Comece com scripts básicos de ciclo de vida fornecidos por HyperPod Você pode encontrar as FSx informações da Amazon no console do Amazon FSx for Lustre em sua conta ou executando o seguinte AWS CLI comando,aws fsx describe-file-systems
."fsx_dns_name": "
fs-12345678a90b01cde
.fsx.us-west-2
.amazonaws.com", "fsx_mountname": "1abcdefg
"
Valide os arquivos JSON de configuração antes de criar um cluster Slurm no HyperPod
Para validar os arquivos de JSON configuração antes de enviar uma solicitação de criação de cluster, use o script de validação de configuração. validate-config.py
provisioning_parameters.json
arquivos create_cluster.json
e da Comece com scripts básicos de ciclo de vida fornecidos por HyperPod seção, execute o script de validação da seguinte maneira.
python3 validate-config.py --cluster-config
create_cluster.json
--provisioning-parametersprovisioning_parameters.json
Veja a seguir um exemplo de saída de uma validação bem-sucedida.
✔️ Validated instance group name worker-group-1 is correct ... ✔️ Validated subnet subnet-012345abcdef67890 ... ✔️ Validated security group sg-012345abcdef67890 ingress rules ... ✔️ Validated security group sg-012345abcdef67890 egress rules ... ✔️ Validated FSx Lustre DNS name fs-012345abcdef67890.fsx.us-east-1.amazonaws.com ✔️ Validated FSx Lustre mount name abcdefgh ✅ Cluster Validation succeeded
Valide o tempo de execução antes de executar cargas de trabalho de produção em um cluster Slurm no HyperPod
Para verificar o tempo de execução antes de executar qualquer carga de trabalho de produção em um cluster do Slurm HyperPod, use o script de validação do tempo de execução. hyperpod-precheck.py
Para executar o script em vários nós ao mesmo tempo, use, srun
conforme mostrado no exemplo a seguir, o comando de execução do script em um cluster do Slurm de 8 nós.
# The following command runs on 8 nodes srun -N
8
python3 hyperpod-precheck.py
nota
Para saber mais sobre o script de validação, como quais funções de validação em tempo de execução o script fornece e diretrizes para resolver problemas que não passam nas validações, consulte Validação em tempo de execução antes de executar cargas de trabalho
Desenvolva scripts de ciclo de vida interativamente em um nó de cluster
Esta seção explica como você pode desenvolver scripts de ciclo de vida interativamente sem criar e excluir repetidamente um cluster. HyperPod
-
Crie um HyperPod cluster com os scripts básicos do ciclo de vida.
-
Faça login em um nó do cluster.
-
Desenvolva um script (
configure_xyz.sh
) editando-o e executando-o repetidamente no nó.-
HyperPod executa os scripts de ciclo de vida como usuário raiz, portanto, recomendamos que você execute o
configure_xyz.sh
como usuário raiz durante o desenvolvimento para garantir que o script seja testado sob as mesmas condições durante a execução do. HyperPod
-
-
Integre o script
lifecycle_script.py
adicionando uma linha de código semelhante à seguinte.ExecuteBashScript("./utils/
configure_xyz.sh
").run() -
Faça upload dos scripts de ciclo de vida atualizados para o bucket do S3 que você usou inicialmente para carregar os scripts de ciclo de vida básicos.
-
Teste a versão integrada do
lifecycle_script.py
criando um novo HyperPod cluster.
Atualize um cluster com scripts de ciclo de vida novos ou atualizados
Há três maneiras de atualizar o HyperPod software.
-
O
UpdateClusterSoftware
API para corrigir o HyperPod software executa novamente os scripts do ciclo de vida em todo o grupo de instâncias. -
O
UpdateCluster
API único executa os scripts de ciclo de vida para novos grupos de instâncias. -
Você também pode executar scripts de ciclo de vida diretamente nas instâncias. HyperPod
Considerações
Considere o seguinte ao usar SageMaker HyperPod.
-
HyperPod é SageMaker HyperPod DLAMI executado em cada instância de um cluster e AMI tem pacotes de software pré-instalados que atendem às compatibilidades e funcionalidades entre eles. HyperPod Observe que, se você reinstalar qualquer um dos pacotes pré-instalados, você será responsável pela instalação de pacotes compatíveis e observe que algumas HyperPod funcionalidades podem não funcionar conforme o esperado.