Skip to main content
NetApp artificial intelligence solutions
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

NetApp AIPod Mini für ERAG - Bereitstellungsschritte

Beitragende Arpitamahajan01
Änderungen vorschlagen

Dieses Dokument bietet eine umfassende Schritt-für-Schritt-Anleitung für die Bereitstellung von NetApp AIPod Mini für Enterprise RAG(ERAG) 2.0. Es behandelt die End-to-End-Installation und -Konfiguration aller Kernkomponenten, einschließlich der Kubernetes-Plattform, NetApp Trident für die Speicherorchestrierung und des ERAG 2.0-Stacks mithilfe von Ansible-Playbooks. Zusätzlich zum Bereitstellungs-Workflow enthält das Dokument einen speziellen Leitfaden zur Fehlerbehebung, der häufig auftretende Probleme während der Installation, deren Ursachen und empfohlene Lösungen erfasst, um eine reibungslose und zuverlässige Bereitstellung zu unterstützen.

Intel-Logo

Sathish Thyagarajan, Michael Oglesby, Arpita Mahajan NetApp

Annahmen:

  • Der Deployment-Benutzer verfügt über ausreichende Berechtigungen, um einen Namespace zu erstellen und Helm-Charts zu installieren.

  • Die Xeon-Server laufen mit Ubuntu 22.04.

  • Auf allen Xeon-Servern ist derselbe Benutzername konfiguriert.

  • DNS-Administrativzugriff ist verfügbar.

  • ONTAP 9.16 mit einer für den S3-Zugriff konfigurierten SVM bereitgestellt.

  • S3-Bucket ist erstellt und konfiguriert.

Voraussetzungen

Installieren Sie Git, Python3.11 und pip für Python3.11

Unter Ubuntu 22.04:

add-apt-repository ppa:deadsnakes/ppa
apt update
apt upgrade
apt install python3.11
python3.11 --version
apt install python3.11-pip
python3.11 -m pip --version

ERAG 2.0/2.0.1 Bereitstellungsschritte

1. Enterprise RAG 2.0-Release von GitHub herunterladen

git clone https://github.com/opea-project/Enterprise-RAG.git
cd Enterprise-RAG/
git checkout tags/release-2.0.0

Für ERAG 2.0.1 verwenden Sie den untenstehenden Befehl

git checkout tags/release-2.0.1

2. Voraussetzungen installieren

cd deployment/
sudo apt-get install python3.11-venv
python3 -m venv erag-venv
source erag-venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
ansible-galaxy collection install -r requirements.yaml --upgrade

3. Inventardatei erstellen

cp -a inventory/sample inventory/<cluster-name>
vi inventory/<cluster-name>/inventory.ini
# Control plane nodes
kube-3 ansible_host=<control_node_ip_address>

# Worker nodes
kube-1 ansible_host=<worker_node1_ip_address>
kube-2 ansible_host=<worker_node2_ip_address>

# Define node groups
[kube_control_plane]
kube-1
kube-2
kube-3

[kube_node]
kube-1
kube-2

[etcd:children]
kube_control_plane

[k8s_cluster:children]
kube_control_plane
kube_node

# Vars
[k8s_cluster:vars]
ansible_become=true
ansible_user=<ssh_username>
ansible_connection=ssh

4. Richten Sie passwortloses SSH zu jedem Knoten ein

ssh-copy-id REMOTE_USER@MACHINE_IP

Hinweis: Wenn ein Deploy-Knoten für die Bereitstellung des ERAG verwendet wird, stellen Sie sicher, dass passwortloses SSH auch auf dem Deploy-Knoten konfiguriert ist.

5. Konnektivität prüfen

ansible all -i inventory/<cluster-name>/inventory.ini -m ping

Hinweis: Falls auf Ihren Knoten kein passwortloses sudo eingerichtet ist, müssen Sie diesem Befehl die Option --ask-become-pass hinzufügen. Bei Verwendung von --ask-become-pass ist es unbedingt erforderlich, dass der SSH-Benutzer auf jedem Knoten dasselbe Passwort verwendet.

6. Datei config.yaml bearbeiten

Bereiten Sie die Bereitstellung vor, indem Sie inventory/<cluster-name>/config.yaml die Konfiguration an die Besonderheiten Ihrer Umgebung anpassen.

vi inventory/<cluster-name>/config.yaml

Beispiel-Snippet:

…
deploy_k8s: true
…
install_csi: "netapp-trident"
…
local_registry: false
…
trident_operator_version: "2510.0"    # Trident operator version (becomes 100.2506.0 in Helm chart)
trident_namespace: "trident"          # Kubernetes namespace for Trident
trident_storage_class: "netapp-trident" # StorageClass name for Trident
trident_backend_name: "ontap-nas"     # Backend configuration name
…
ontap_management_lif: "<ontap_mgmt_lif>"              # ONTAP management LIF IP address
ontap_data_lif: "<ontap_nfs_data_lif>"                    # ONTAP data LIF IP address
ontap_svm: "<ontap_svm>"                         # Storage Virtual Machine (SVM) name
ontap_username: "<ontap_username>"                    # ONTAP username with admin privileges
ontap_password: "<redacted>"                    # ONTAP password
ontap_aggregate: "<ontap_aggr>"                   # ONTAP aggregate name for volume creation
…
kubeconfig: "<repository path>/deployment/inventory/<cluster-name>/artifacts/admin.conf"
…

7. Stellen Sie den K8s-Cluster bereit (mit Trident)

Führen Sie ansible-playbook playbooks/infrastructure.yaml mit den Tags configure und install aus, um den Cluster und Trident CSI bereitzustellen.

ansible-playbook playbooks/infrastructure.yaml --tags configure,install -i inventory/<cluster-name>/inventory.ini -e @inventory/<cluster-name>/config.yaml

Hinweis: - Falls Sie auf Ihren Knoten kein passwortloses sudo eingerichtet haben, müssen Sie --ask-become-pass zu diesem Befehl hinzufügen. Bei der Verwendung von --ask-become-pass ist es unbedingt erforderlich, dass der SSH-Benutzer auf jedem Knoten dasselbe Passwort hat. - Siehe "NetApp Trident CSI Integration für Enterprise RAG" für Details. Siehe "Trident -Installationsdokumentation" für weitere Details.

8. Ändern Sie die Anzahl der iwatch-Open-Deskriptoren

Weitere Einzelheiten finden Sie in der "iwatch offene Beschreibungen".

9. Installieren Sie kubectl

Siehe "Installieren Sie Kubectl", falls es noch nicht installiert ist. Rufen Sie die kubeconfig-Datei von <repository path>/deployment/inventory/<cluster-name>/artifacts/admin.conf ab.

10. MetalLB im Kubernetes-Cluster installieren

Installieren Sie MetalLB mithilfe von helm auf Ihrem Kubernetes-Cluster.

helm repo add metallb https://metallb.github.io/metallb
helm -n metallb-system install metallb metallb/metallb --create-namespace

Weitere Einzelheiten finden Sie in der "MetalLB-Installation".

11. MetalLB konfigurieren

MetalLB wurde im Layer-2-Modus konfiguriert, und die erforderlichen IPAddressPool- und L2Advertisement-Ressourcen wurden gemäß den dokumentierten Konfigurationsrichtlinien erstellt.

vi metallb-ipaddrpool-l2adv.yaml
kubectl apply -f metallb-ipaddrpool-l2adv.yaml

Beispiel-Snippet:

vi metallb-ipaddrpool-l2adv.yaml
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: erag
  namespace: metallb-system
spec:
  addresses:
  - <IPAddressPool>
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: metallb-l2adv
  namespace: metallb-system

Hinweis: - Verwenden Sie metallb-system als Namespace für MetalLB IPAddressPool und L2Advertisement. - Der IP-Adresspool kann alle ungenutzten IPs innerhalb desselben Subnetzes wie die Kubernetes-Knoten enthalten. Für ERAG wird nur eine einzige IP-Adresse benötigt. - Siehe "MetalLB Layer2-Konfiguration" für Details.

12. Aktualisieren Sie die Datei config.yaml mit FQDN, Volume-Zugriffsmodus, Ingress und S3-Details.

Ändern Sie die Datei config.yaml unter inventory/<cluster-name>/config.yaml , um den FQDN für die Bereitstellung zu definieren, die Zugriffsmodi für die Volumes festzulegen, die Ingress-Exposition zu konfigurieren und ONTAP S3 zu integrieren.

Bearbeiten config.yaml und wenden Sie die folgenden Konfigurationsänderungen an:

  • FQDN: Geben Sie die vollqualifizierte Domain an, die für den Zugriff auf die Bereitstellung verwendet wird.

  • Zugriffsmodus für Volumes: Im Abschnitt gmc.pvc accessMode: ReadWriteMany so einstellen, dass der gleichzeitige Zugriff auf Modellvolumes über mehrere Pods hinweg unterstützt wird.

  • Ingress-Konfiguration: Konfigurieren Sie den Ingress service_type als LoadBalancer, um externen Zugriff auf die Anwendung zu ermöglichen.

  • S3-Speicherdetails: Setzen Sie storageType auf s3compatible und konfigurieren Sie ONTAP S3-Parameter, einschließlich Region, Zugangsdaten sowie interne und externe Endpunkte.

  • SSL-Zertifikatsprüfung: Setzen Sie edpInternalCertVerify und edpExternalCertVerify nur dann auf false, wenn ONTAP S3 mit selbstsignierten Zertifikaten konfiguriert ist. Wenn Zertifikate von einer öffentlich vertrauenswürdigen CA ausgestellt werden, sollten diese Parameter aktiviert bleiben.

Beispiel-Snippet:

vi inventory/<cluster-name>/config.yaml
…
FQDN: "<FQDN>" # Provide the FQDN for the deployment
…
gmc:
  enabled: true
  pvc:
    accessMode: ReadWriteMany # AccessMode
    models:
      modelLlm:
        name: model-volume-llm
        storage: 100Gi
      modelEmbedding:
        name: model-volume-embedding
        storage: 20Gi
      modelReranker:
        name: model-volume-reranker
        storage: 10Gi
…
ingress:
  …
  service_type: LoadBalancer
  …
edp:
  …
  storageType: s3compatible
  …
  s3compatible:
    region: "us-east-1"
    accessKeyId: "<your_access_key>"
    secretAccessKey: "<your_secret_key>"
    internalUrl: "https://<IP-address>"
    externalUrl: "https://<IP-address>"
    bucketNameRegexFilter: ".*"
    edpExternalCertVerify: false
    edpInternalCertVerify: false
  …

Hinweis: - Standardmäßig erfasst die Intel​ AI for Enterprise RAG-Anwendung Daten aus allen vorhandenen Buckets in Ihrer SVM. Wenn Sie mehrere Buckets in Ihrer SVM haben, können Sie das bucketNameRegexFilter Feld so anpassen, dass Daten nur aus bestimmten Buckets erfasst werden. - Weitere Informationen finden Sie in der "Intel​ AI for Enterprise RAG-Bereitstellung" Dokumentation.

13. Konfigurieren Sie die Einstellungen für die geplante Synchronisierung

Aktivieren Sie bei der Installation der OPEA for Intel​ AI for Enterprise RAG-Anwendung scheduledSync, damit die Anwendung neue oder aktualisierte Dateien automatisch aus Ihren S3-Buckets aufnimmt.

Wann scheduledSync aktiviert ist, überprüft die Anwendung Ihre Quell-S3-Buckets automatisch auf neue oder aktualisierte Dateien. Alle neuen oder aktualisierten Dateien, die im Rahmen dieses Synchronisierungsprozesses gefunden werden, werden automatisch aufgenommen und der RAG-Wissensdatenbank hinzugefügt. Die Anwendung überprüft Ihre Quell-Buckets basierend auf einem voreingestellten Zeitintervall. Das Standardzeitintervall beträgt 60 Sekunden, was bedeutet, dass die Anwendung alle 60 Sekunden nach Änderungen sucht. Möglicherweise möchten Sie dieses Intervall Ihren speziellen Anforderungen entsprechend ändern.

Um scheduledSync und das Synchronisierungsintervall zu aktivieren und festzulegen, setzen Sie die folgenden Werte in deployment/components/edp/values.yaml:

vi components/edp/values.yaml
…
presignedUrlCredentialsSystemFallback: "true"
…
celery:
  …
  config:
    …
    scheduledSync:
      enabled: true
      syncPeriodSeconds: "60"
…

14. Enterprise RAG 2.0/2.0.1 bereitstellen

Vor der Installation validieren Sie die Infrastrukturbereitschaft, indem Sie den im "Intel​ AI for Enterprise RAG-Anwendungsbereitstellungsleitfaden" beschriebenen Verfahren folgen. Dieser Schritt stellt sicher, dass die zugrunde liegende Infrastruktur korrekt konfiguriert ist und alle Voraussetzungen für eine erfolgreiche Enterprise RAG Application-Installation erfüllt.

Führen Sie die Installation mit aus:

ansible-playbook -u $USER playbooks/application.yaml --tags configure,install -e @inventory/<cluster-name>/config.yaml

Hinweis: Falls auf Ihrem Bereitstellungsknoten (dem Laptop oder Jump-Host, auf dem Sie den Befehl ansible-playbook ausführen) kein passwortloses sudo eingerichtet ist, müssen Sie --ask-become-pass zu diesem Befehl hinzufügen. Bei der Verwendung von --ask-become-pass ist es unbedingt erforderlich, dass der SSH-Benutzer auf jedem Knoten das gleiche Passwort verwendet.

15. Erstellen Sie einen DNS-Eintrag

Erstellen Sie einen DNS-Eintrag für das Enterprise RAG-Web-Dashboard auf Ihrem DNS-Server. Um fortzufahren, rufen Sie die dem Enterprise RAG-Ingress zugewiesene externe IP-Adresse ab LoadBalancer:

kubectl -n ingress-nginx get svc ingress-nginx-controller

Erstellen Sie einen DNS-Eintrag, der auf diese IP-Adresse für den FQDN zeigt, den Sie in Schritt 12 verwendet haben.

Hinweis: - Der für den DNS-Eintrag verwendete FQDN MUSS mit dem FQDN aus der config file übereinstimmen.

16. Zugriff auf die Enterprise RAG UI

Greifen Sie auf die Enterprise RAG-Benutzeroberfläche zu, indem Sie in Ihrem Browser zu diesem FQDN navigieren. Hinweis: Sie können die Standard-Benutzeroberflächen-Anmeldeinformationen mit abrufen.

Leitfaden zur Fehlerbehebung

1. Problem: Keycloak Helm Installationskonflikt

Szenario: Bei der Bereitstellung von ERAG kann die Keycloak-Installation mit folgendem Fehler fehlschlagen:

FAILED - RETRYING: [localhost]: Install Keycloak Helm chart (5 retries left).
Failure when executing Helm command. Exited 1.
    stdout:
    stderr: Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress

Maßnahme: Wenn der Fehler nach wiederholten Versuchen weiterhin besteht, deinstallieren Sie die ERAG-Bereitstellung, löschen Sie den vorhandenen auth-Namespace mit den untenstehenden Befehlen und führen Sie die Bereitstellung erneut aus.

ansible-playbook playbooks/application.yaml --tags uninstall -e @inventory/<cluster-name>/config.yaml

helm -n auth uninstall keycloak
kubectl -n auth get pvc # confirm all PVCs are gone; if any are left, delete them
kubectl delete ns auth

Hinweis: Ein veralteter Helm-Release-Status kann nachfolgende Installations- oder Upgrade-Vorgänge blockieren.

2. Problem: Trident Operator Helm Chart-Version nicht gefunden

Szenario: Während der ERAG-Bereitstellung kann die Installation des Trident-Operators aufgrund einer Helm-Chart-Versionsinkompatibilität fehlschlagen. Der folgende Fehler kann auftreten:

TASK [netapp_trident_csi_setup : Install Trident operator via Helm]
fatal: [localhost]: FAILED! => changed=false
  command: /usr/local/bin/helm --version=100.2510.0 show chart 'netapp-trident/trident-operator'
  msg: |-
    Failure when executing Helm command. Exited 1.
    stdout:
    stderr: Error: chart "trident-operator" matching 100.2510.0 not found in netapp-trident index.
            (try 'helm repo update'): no chart version found for trident-operator-100.2510.0

Maßnahme: Wenn dieser Fehler auftritt, aktualisieren Sie den Helm-Repository-Index und führen Sie das Deployment-Playbook erneut aus.

helm repo update
ansible-playbook playbooks/application.yaml -e @inventory/<cluster-name>/config.yaml

Hinweis: Dies ist ein bekanntes Problem in ERAG Version 2.0. Ein Fix wurde eingereicht und wird in einer zukünftigen Version enthalten sein.