Для чистого Markdown-содержимого этой страницы добавьте .md к этому URL. Полный индекс документации см. в https://docs.nvidia.com/dynamo/llms.txt. Полный контент, включая справочник API и примеры SDK, см. в https://docs.nvidia.com/dynamo/llms-full.txt.

Настройка Amazon EFS для EKS

Создание файловой системы Amazon EFS для Amazon EKS

Это руководство показывает, как создать файловую систему Amazon EFS и подключить ее к вашему кластеру EKS. Драйвер EFS CSI уже был установлен как дополнение через eksctl.yaml во время создания кластера. Теперь нужно создать саму файловую систему и сделать ее доступной для нагрузок Kubernetes.

Эта файловая система будет использоваться Dynamo для хранения общих весов модели и кеша компиляции между узлами.

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

Кластер EKS, созданный по руководству по EKS
Environment variables set:

export AWS_REGION="us-east-1"
export CLUSTER_NAME="ai-dynamo"
export DYNAMO_NAMESPACE="dynamo-system"

Получение информации о VPC и подсетях

Получите идентификатор VPC, связанного с вашим кластером EKS:

export VPC_ID=$(aws eks describe-cluster \
  --name $CLUSTER_NAME \
  --region $AWS_REGION \
  --query "cluster.resourcesVpcConfig.vpcId" \
  --output text)

Получите диапазон CIDR для VPC (он используется для правила группы безопасности):

export VPC_CIDR=$(aws ec2 describe-vpcs \
  --vpc-ids $VPC_ID \
  --query "Vpcs[0].CidrBlock" \
  --output text)

Создание группы безопасности для EFS

Создайте группу безопасности, которая разрешает трафик NFS (порт 2049) изнутри VPC:

export EFS_SG_ID=$(aws ec2 create-security-group \
  --group-name dynamo-efs-sg \
  --description "Security group for EFS access from EKS" \
  --vpc-id $VPC_ID \
  --region $AWS_REGION \
  --query "GroupId" \
  --output text)

Добавьте входящее правило, разрешающее трафик NFS из CIDR VPC:

aws ec2 authorize-security-group-ingress \
  --group-id $EFS_SG_ID \
  --protocol tcp \
  --port 2049 \
  --cidr $VPC_CIDR \
  --region $AWS_REGION

Создание файловой системы EFS

export EFS_FS_ID=$(aws efs create-file-system \
  --performance-mode generalPurpose \
  --throughput-mode elastic \
  --encrypted \
  --region $AWS_REGION \
  --tags Key=Name,Value=dynamo-efs \
  --query "FileSystemId" \
  --output text)

Подождите, пока файловая система станет доступной:

aws efs describe-file-systems \
  --file-system-id $EFS_FS_ID \
  --region $AWS_REGION \
  --query "FileSystems[0].LifeCycleState" \
  --output text

Перед продолжением вы должны увидеть available.

Создание точек монтирования

Точки монтирования позволяют узлам EKS получать доступ к файловой системе EFS. Для каждой подсети, в которой работают ваши узлы, нужна одна точка монтирования.

Получите идентификаторы подсетей, которые использует ваш кластер EKS:

export SUBNET_IDS=$(aws eks describe-cluster \
  --name $CLUSTER_NAME \
  --region $AWS_REGION \
  --query "cluster.resourcesVpcConfig.subnetIds[]" \
  --output text)

echo "Subnet IDs: $SUBNET_IDS"

Создайте точку монтирования в каждой подсети:

for SUBNET_ID in $(echo "$SUBNET_IDS" | tr '\t' '\n'); do
  echo "Creating mount target in subnet: $SUBNET_ID"
  aws efs create-mount-target \
    --file-system-id $EFS_FS_ID \
    --subnet-id $SUBNET_ID \
    --security-groups $EFS_SG_ID \
    --region $AWS_REGION 2>/dev/null || echo "  Mount target already exists or subnet is in a duplicate AZ (this is OK)"
done

EFS допускает только одну точку монтирования на Availability Zone. Если несколько подсетей находятся в одной AZ, команда завершится ошибкой для дублей, и это ожидаемо, поэтому это можно безопасно игнорировать.

Проверьте, что точки монтирования доступны:

aws efs describe-mount-targets \
  --file-system-id $EFS_FS_ID \
  --region $AWS_REGION \
  --query "MountTargets[*].{SubnetId:SubnetId,AZ:AvailabilityZoneName,State:LifeCycleState}" \
  --output table

Подождите, пока все точки монтирования не покажут available в столбце State, прежде чем продолжить.

Создание StorageClass Kubernetes

Создайте StorageClass, который использует драйвер EFS CSI с динамическим выделением:

kubectl apply -f - << EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc-dynamic
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: "${EFS_FS_ID}"
  directoryPerms: "777"
  uid: "1000"
  gid: "1000"
EOF

Создание PersistentVolumeClaim

Мы создаем три отдельных PVC, потому что разные примеры рецептов Dynamo ссылаются на каждый из них по отдельности:

model-cache хранит загруженные веса модели (например, из HuggingFace).
compilation-cache хранит артефакты компиляции vLLM/TRT-LLM.
perf-cache хранит трассировки бенчмарков и результаты производительности.

# Создать пространство имен, которое мы будем использовать для Dynamo, если оно еще не существует
kubectl create namespace ${DYNAMO_NAMESPACE}

# Create PVCs
kubectl apply -f - << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: model-cache
  namespace: ${DYNAMO_NAMESPACE}
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: "efs-sc-dynamic"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: compilation-cache
  namespace: ${DYNAMO_NAMESPACE}
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: "efs-sc-dynamic"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: perf-cache
  namespace: ${DYNAMO_NAMESPACE}
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: "efs-sc-dynamic"
EOF

EFS является эластичной, значение storage в PVC требуется Kubernetes, но не ограничивает фактический объем хранения. EFS будет автоматически увеличиваться и уменьшаться.

Проверка

Убедитесь, что PVC привязан:

kubectl get pvc -n ${DYNAMO_NAMESPACE}

Вы должны увидеть вывод, похожий на следующий:

NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     VOLUMEATTRIBUTESCLASS   AGE
compilation-cache   Bound    pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   5Gi        RWX            efs-sc-dynamic   <unset>                 41s
model-cache         Bound    pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   5Gi        RWX            efs-sc-dynamic   <unset>                 42s
perf-cache          Bound    pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   5Gi        RWX            efs-sc-dynamic   <unset>                 41s

Очистка

Чтобы удалить ресурсы EFS, когда они больше не нужны:

# Delete the Kubernetes resources
kubectl delete pvc model-cache compilation-cache perf-cache -n ${DYNAMO_NAMESPACE}
kubectl delete storageclass efs-sc-dynamic

# Delete mount targets
for MT_ID in $(aws efs describe-mount-targets --file-system-id $EFS_FS_ID --region $AWS_REGION --query "MountTargets[*].MountTargetId" --output text); do
  aws efs delete-mount-target --mount-target-id $MT_ID --region $AWS_REGION
done

# Delete the EFS file system
aws efs delete-file-system --file-system-id $EFS_FS_ID --region $AWS_REGION

# Delete the security group
aws ec2 delete-security-group --group-id $EFS_SG_ID --region $AWS_REGION

Создание файловой системы Amazon EFS для Amazon EKS

Предварительные требования​

Получение информации о VPC и подсетях​

Создание группы безопасности для EFS​

Создание файловой системы EFS​

Создание точек монтирования​

Создание StorageClass Kubernetes​

Создание PersistentVolumeClaim​

Проверка​

Очистка​