Нет экземпляров GPU EC2, связанных с AWS Batch

Мне нужно настроить экземпляры с поддержкой графического процессора в AWS Batch.

Вот мой файл .yaml:

  GPULargeLaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateData:
        UserData:
          Fn::Base64:
            Fn::Sub: |
              MIME-Version: 1.0
              Content-Type: multipart/mixed; boundary = "==BOUNDARY= = "

              --==BOUNDARY==
              Content-Type: text/cloud-config; charset = "us-ascii"

              runcmd:
                - yum install -y aws-cfn-bootstrap
                - echo ECS_LOGLEVEL=debug >> /etc/ecs/ecs.config
                - echo ECS_IMAGE_CLEANUP_INTERVAL=60m >> /etc/ecs/ecs.config
                - echo ECS_IMAGE_MINIMUM_CLEANUP_AGE=60m >> /etc/ecs/ecs.config
                - /opt/aws/bin/cfn-init -v --region us-west-2 --stack cool_stack --resource LaunchConfiguration
                - echo "DEVS=/dev/xvda" > /etc/sysconfig/docker-storage-setup
                - echo "VG=docker" >> /etc/sysconfig/docker-storage-setup
                - echo "DATA_SIZE=99%FREE" >> /etc/sysconfig/docker-storage-setup
                - echo "AUTO_EXTEND_POOL=yes" >> /etc/sysconfig/docker-storage-setup
                - echo "LV_ERROR_WHEN_FULL=yes" >> /etc/sysconfig/docker-storage-setup
                - echo "EXTRA_STORAGE_OPTIONS=\"--storage-opt dm.fs=ext4 --storage-opt dm.basesize=64G\"" >> /etc/sysconfig/docker-storage-setup
                - /usr/bin/docker-storage-setup
                - yum update -y
                - echo "OPTIONS=\"--default-ulimit nofile=1024000:1024000 --storage-opt dm.basesize=64G\"" >> /etc/sysconfig/docker
                - /etc/init.d/docker restart

              --==BOUNDARY==--
      LaunchTemplateName: GPULargeLaunchTemplate

  GPULargeBatchComputeEnvironment:
    DependsOn:
      - ComputeRole
      - ComputeInstanceProfile
    Type: AWS::Batch::ComputeEnvironment
    Properties:
      Type: MANAGED
      ComputeResources:
        ImageId: ami-GPU-optimized-AMI-ID
        AllocationStrategy: BEST_FIT_PROGRESSIVE
        LaunchTemplate:
          LaunchTemplateId:
            Ref: GPULargeLaunchTemplate
          Version:
            Fn::GetAtt:
              - GPULargeLaunchTemplate
              - LatestVersionNumber
        InstanceRole:
          Ref: ComputeInstanceProfile
        InstanceTypes:
          - g4dn.xlarge
        MaxvCpus: 768
        MinvCpus: 1
        SecurityGroupIds:
          - Fn::GetAtt:
              - ComputeSecurityGroup
              - GroupId
        Subnets:
          - Ref: ComputePrivateSubnetA
        Type: EC2
        UpdateToLatestImageVersion: True

  MyGPUBatchJobQueue:
    Type: AWS::Batch::JobQueue
    Properties:
      ComputeEnvironmentOrder:
        - ComputeEnvironment:
            Ref: GPULargeBatchComputeEnvironment
          Order: 1
      Priority: 5
      JobQueueName: MyGPUBatchJobQueue
      State: ENABLED

  MyGPUJobDefinition:
    Type: AWS::Batch::JobDefinition
    Properties:
      Type: container
      ContainerProperties:
        Command:
          - "/opt/bin/python3"
          - "/opt/bin/start.py"
          - "--retry_count"
          - "Ref::batchRetryCount"
          - "--retry_limit"
          - "Ref::batchRetryLimit"
        Environment:
          - Name: "Region"
            Value: "us-west-2"
          - Name: "LANG"
            Value: "en_US.UTF-8"
        Image:
          Fn::Sub: "cool_1234_abc.dkr.ecr.us-west-2.amazonaws.com/my-image"
        JobRoleArn:
          Fn::Sub: "arn:aws:iam::cool_1234_abc:role/ComputeRole"
        Memory: 16000
        Vcpus: 1
        ResourceRequirements:
          - Type: GPU
            Value: '1'
      JobDefinitionName: MyGPUJobDefinition
      Timeout:
        AttemptDurationSeconds: 500

Когда я начинаю задание, оно навсегда зависает в состоянии RUNNABLE, тогда я сделал следующее:

  1. Когда я поменял тип экземпляра на обычные типы ЦП, повторно развернул стек CF, отправил задание, и задание можно было запустить и завершить успешно, значит, что-то не хватает/неправильно в том, как я использую эти типы экземпляров графического процессора в AWS Batch;
  2. Затем я нашел этот пост, поэтому добавил поле ImageId в свою ComputeEnvironment с известным AMI, оптимизированным для графического процессора, но все равно безуспешно;
  3. Я провел параллельное сравнение заданий между работающим процессором AWS Batch и неработающим графическим процессором AWS Batch, запустив aws batch describe-jobs --jobs AWS_BATCH_JOB_EXECUTION_ID --region us-west-2, я обнаружил, что между ними не хватает: containerInstanceArn и taskArn, где в нерабочем экземпляре графического процессора эти два поля просто отсутствуют.
  4. Я обнаружил, что в группе ASG (группа автоматического масштабирования), созданной вычислительной средой, этот экземпляр графического процессора находится в этом ASG, но когда я захожу в ECS и выбираю этот кластер графического процессора, с ним не связаны никакие экземпляры контейнера, в отличие от рабочего процессора. те, где кластер ECS содержит экземпляры контейнера.

Будем очень признательны за любые идеи, как это исправить!


102
1

Ответ:

Решено

Это, безусловно, отличное обучение. Вот что я сделал, нашел и решил эту проблему:

  1. Это сводится к тому, что мой недавно запущенный экземпляр GPU не может присоединиться к кластеру ECS (оба запускаются с помощью приведенного выше шаблона yaml CloudFormation);
  2. Выполните некоторые первые проверки: vpc, подсеть, группы безопасности, чтобы увидеть, не блокирует ли что-либо/не препятствует присоединению нового экземпляра графического процессора к кластеру ECS;
  3. Выполните действия по устранению неполадок здесь: https://repost.aws/knowledge-center/batch-job-stuck-runnable-status
  4. В приведенной выше ссылке есть это AWSSupport-TroubleshootAWSBatchJob runbook, которое может оказаться полезным (убедитесь, что вы выбрали правильный регион) перед бегом;
  5. Подключитесь к экземпляру графического процессора и установите сборщик журналов ECS: https://github.com/aws/amazon-ecs-logs-collector
  6. Проверьте свои журналы, вот, я нашел проблему:
30T01:19:48Z msg = "Nvidia GPU Manager: setup failed: error initializing nvidia nvml: nvml: Driver/library version mismatch"
Mar 30 01:19:48 ip-10-0-163-202.us-west-2.compute.internal systemd[1]: ecs.service: control process exited, code=exited status=255
Mar 30 01:19:48 ip-10-0-163-202.us-west-2.compute.internal kernel: NVRM: API mismatch: the client has the version 535.161.07, but
                                                                   NVRM: this kernel module has the version 470.182.03.  Please
                                                                   NVRM: make sure that this kernel module and all NVIDIA driver
                                                                   NVRM: components have the same version.
  1. Итак, почему-то мой CDK не знал, как загрузить последнюю версию AMI, оптимизированную для экземпляров графического процессора (теоретически, это должно быть согласно aws doc ), что привело к несоответствию версий, тогда я перешел на https:// github.com/aws/amazon-ecs-ami/releases чтобы найти последний идентификатор AMI: ami-019d947e77874eaee, затем добавьте это поле: ImageId: ami-019d947e77874eaee в моем шаблоне повторно разверните, затем вы можете использовать несколько команд, чтобы проверить статус вашего Экземпляр GPU EC2: systemctl status ecs должен быть запущен и запущен, чтобы ваш графический процессор мог присоединиться к вашему кластеру ECS, sudo docker info должен вернуть информацию, показывающую, что он работает, nvidia-smi должен вернуть информацию, показывающую, что ваш драйвер nvidia правильно установлен и работает, пример информации:
Sat Mar 30 13:47:46 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.161.07             Driver Version: 535.161.07   CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla T4                       On  | 00000000:00:1E.0 Off |                    0 |
| N/A   20C    P8               9W /  70W |      2MiB / 15360MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+
  1. Ого! Если все это сработает, ваш AWS Batch с поддержкой графического процессора сможет успешно выполнять запланированные задания и запускаться! :)