Milvus-Cluster-Setup mit Kubernetes vor Ort
Änderungen vorschlagen
PDFs
In diesem Abschnitt wird die Einrichtung des Milvus-Clusters für die Vector-Datenbanklösung für NetApp erläutert.
Milvus-Cluster-Setup mit Kubernetes vor Ort
Kunden stehen vor der Herausforderung, Speicher und Rechenleistung unabhängig zu skalieren und eine effektive Infrastruktur- und Datenverwaltung zu gewährleisten. Kubernetes und Vektordatenbanken bilden zusammen eine leistungsstarke, skalierbare Lösung für die Verwaltung großer Datenvorgänge. Kubernetes optimiert Ressourcen und verwaltet Container, während Vektordatenbanken hochdimensionale Daten und Ähnlichkeitssuchen effizient verarbeiten. Diese Kombination ermöglicht die schnelle Verarbeitung komplexer Abfragen großer Datensätze und lässt sich nahtlos mit wachsenden Datenmengen skalieren, was sie ideal für Big-Data-Anwendungen und KI-Workloads macht.
-
In diesem Abschnitt beschreiben wir detailliert den Prozess der Installation eines Milvus-Clusters auf Kubernetes unter Verwendung eines NetApp -Speichercontrollers sowohl für Clusterdaten als auch für Kundendaten.
-
Zur Installation eines Milvus-Clusters sind Persistent Volumes (PVs) zum Speichern von Daten aus verschiedenen Milvus-Clusterkomponenten erforderlich. Zu diesen Komponenten gehören etcd (drei Instanzen), pulsar-bookie-journal (drei Instanzen), pulsar-bookie-ledgers (drei Instanzen) und pulsar-zookeeper-data (drei Instanzen).
Im Milvus-Cluster können wir entweder Pulsar oder Kafka als zugrunde liegende Engine verwenden, die die zuverlässige Speicherung und Veröffentlichung/Abonnementierung von Nachrichtenströmen im Milvus-Cluster unterstützt. Für Kafka mit NFS hat NetApp Verbesserungen in ONTAP 9.12.1 und höher vorgenommen. Diese Verbesserungen sowie NFSv4.1- und Linux-Änderungen, die in RHEL 8.7 oder 9.1 und höher enthalten sind, beheben das Problem der „dummen Umbenennung“, das beim Ausführen von Kafka über NFS auftreten kann. Wenn Sie an ausführlicheren Informationen zum Ausführen von Kafka mit der NetApp NFS-Lösung interessiert sind, lesen Sie bitte -"dieser Link" . -
Wir haben ein einzelnes NFS-Volume von NetApp ONTAP erstellt und 12 persistente Volumes mit jeweils 250 GB Speicher eingerichtet. Die Speichergröße kann je nach Clustergröße variieren. Beispielsweise haben wir einen anderen Cluster, bei dem jedes PV über 50 GB verfügt. Weitere Einzelheiten finden Sie unten in einer der PV-YAML-Dateien. Insgesamt hatten wir 12 solcher Dateien. In jeder Datei ist der storageClassName auf „default“ gesetzt und Speicher und Pfad sind für jedes PV eindeutig.
root@node2:~# cat sai_nfs_to_default_pv1.yaml apiVersion: v1 kind: PersistentVolume metadata: name: karthik-pv1 spec: capacity: storage: 250Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: default local: path: /vectordbsc/milvus/milvus1 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node2 - node3 - node4 - node5 - node6 root@node2:~# -
Führen Sie den Befehl „kubectl apply“ für jede PV-YAML-Datei aus, um die persistenten Volumes zu erstellen, und überprüfen Sie anschließend deren Erstellung mit „kubectl get pv“.
root@node2:~# for i in $( seq 1 12 ); do kubectl apply -f sai_nfs_to_default_pv$i.yaml; done persistentvolume/karthik-pv1 created persistentvolume/karthik-pv2 created persistentvolume/karthik-pv3 created persistentvolume/karthik-pv4 created persistentvolume/karthik-pv5 created persistentvolume/karthik-pv6 created persistentvolume/karthik-pv7 created persistentvolume/karthik-pv8 created persistentvolume/karthik-pv9 created persistentvolume/karthik-pv10 created persistentvolume/karthik-pv11 created persistentvolume/karthik-pv12 created root@node2:~# -
Zum Speichern von Kundendaten unterstützt Milvus Objektspeicherlösungen wie MinIO, Azure Blob und S3. In dieser Anleitung verwenden wir S3. Die folgenden Schritte gelten sowohl für den ONTAP S3- als auch für den StorageGRID Objektspeicher. Wir verwenden Helm, um den Milvus-Cluster bereitzustellen. Laden Sie die Konfigurationsdatei values.yaml vom Milvus-Download-Speicherort herunter. Die Datei values.yaml, die wir in diesem Dokument verwendet haben, finden Sie im Anhang.
-
Stellen Sie sicher, dass die „storageClass“ in jedem Abschnitt auf „default“ gesetzt ist, einschließlich der Abschnitte für Protokoll, etcd, Zookeeper und Bookkeeper.
-
Deaktivieren Sie MinIO im Abschnitt MinIO.
-
Erstellen Sie einen NAS-Bucket aus dem ONTAP oder StorageGRID Objektspeicher und fügen Sie ihn mit den Objektspeicher-Anmeldeinformationen in ein externes S3 ein.
################################### # External S3 # - these configs are only used when `externalS3.enabled` is true ################################### externalS3: enabled: true host: "192.168.150.167" port: "80" accessKey: "24G4C1316APP2BIPDE5S" secretKey: "Zd28p43rgZaU44PX_ftT279z9nt4jBSro97j87Bx" useSSL: false bucketName: "milvusdbvol1" rootPath: "" useIAM: false cloudProvider: "aws" iamEndpoint: "" region: "" useVirtualHost: false -
Stellen Sie vor dem Erstellen des Milvus-Clusters sicher, dass der PersistentVolumeClaim (PVC) keine bereits vorhandenen Ressourcen enthält.
root@node2:~# kubectl get pvc No resources found in default namespace. root@node2:~# -
Verwenden Sie Helm und die Konfigurationsdatei values.yaml, um den Milvus-Cluster zu installieren und zu starten.
root@node2:~# helm upgrade --install my-release milvus/milvus --set global.storageClass=default -f values.yaml Release "my-release" does not exist. Installing it now. NAME: my-release LAST DEPLOYED: Thu Mar 14 15:00:07 2024 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None root@node2:~# -
Überprüfen Sie den Status der PersistentVolumeClaims (PVCs).
root@node2:~# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE data-my-release-etcd-0 Bound karthik-pv8 250Gi RWO default 3s data-my-release-etcd-1 Bound karthik-pv5 250Gi RWO default 2s data-my-release-etcd-2 Bound karthik-pv4 250Gi RWO default 3s my-release-pulsar-bookie-journal-my-release-pulsar-bookie-0 Bound karthik-pv10 250Gi RWO default 3s my-release-pulsar-bookie-journal-my-release-pulsar-bookie-1 Bound karthik-pv3 250Gi RWO default 3s my-release-pulsar-bookie-journal-my-release-pulsar-bookie-2 Bound karthik-pv1 250Gi RWO default 3s my-release-pulsar-bookie-ledgers-my-release-pulsar-bookie-0 Bound karthik-pv2 250Gi RWO default 3s my-release-pulsar-bookie-ledgers-my-release-pulsar-bookie-1 Bound karthik-pv9 250Gi RWO default 3s my-release-pulsar-bookie-ledgers-my-release-pulsar-bookie-2 Bound karthik-pv11 250Gi RWO default 3s my-release-pulsar-zookeeper-data-my-release-pulsar-zookeeper-0 Bound karthik-pv7 250Gi RWO default 3s root@node2:~# -
Überprüfen Sie den Status der Pods.
root@node2:~# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES <content removed to save page space>Bitte stellen Sie sicher, dass der Pod-Status „läuft“ lautet und wie erwartet funktioniert.
-
Testen Sie das Schreiben und Lesen von Daten im Milvus- und NetApp Objektspeicher.
-
Schreiben Sie Daten mit dem Python-Programm „prepare_data_netapp_new.py“.
root@node2:~# date;python3 prepare_data_netapp_new.py ;date Thu Apr 4 04:15:35 PM UTC 2024 === start connecting to Milvus === === Milvus host: localhost === Does collection hello_milvus_ntapnew_update2_sc exist in Milvus: False === Drop collection - hello_milvus_ntapnew_update2_sc === === Drop collection - hello_milvus_ntapnew_update2_sc2 === === Create collection `hello_milvus_ntapnew_update2_sc` === === Start inserting entities === Number of entities in hello_milvus_ntapnew_update2_sc: 3000 Thu Apr 4 04:18:01 PM UTC 2024 root@node2:~# -
Lesen Sie die Daten mithilfe der Python-Datei „verify_data_netapp.py“.
root@node2:~# python3 verify_data_netapp.py === start connecting to Milvus === === Milvus host: localhost === Does collection hello_milvus_ntapnew_update2_sc exist in Milvus: True {'auto_id': False, 'description': 'hello_milvus_ntapnew_update2_sc', 'fields': [{'name': 'pk', 'description': '', 'type': <DataType.INT64: 5>, 'is_primary': True, 'auto_id': False}, {'name': 'random', 'description': '', 'type': <DataType.DOUBLE: 11>}, {'name': 'var', 'description': '', 'type': <DataType.VARCHAR: 21>, 'params': {'max_length': 65535}}, {'name': 'embeddings', 'description': '', 'type': <DataType.FLOAT_VECTOR: 101>, 'params': {'dim': 16}}]} Number of entities in Milvus: hello_milvus_ntapnew_update2_sc : 3000 === Start Creating index IVF_FLAT === === Start loading === === Start searching based on vector similarity === hit: id: 2998, distance: 0.0, entity: {'random': 0.9728033590489911}, random field: 0.9728033590489911 hit: id: 2600, distance: 0.602496862411499, entity: {'random': 0.3098157043984633}, random field: 0.3098157043984633 hit: id: 1831, distance: 0.6797959804534912, entity: {'random': 0.6331477114129169}, random field: 0.6331477114129169 hit: id: 2999, distance: 0.0, entity: {'random': 0.02316334456872482}, random field: 0.02316334456872482 hit: id: 2524, distance: 0.5918987989425659, entity: {'random': 0.285283165889066}, random field: 0.285283165889066 hit: id: 264, distance: 0.7254047393798828, entity: {'random': 0.3329096143562196}, random field: 0.3329096143562196 search latency = 0.4533s === Start querying with `random > 0.5` === query result: -{'random': 0.6378742006852851, 'embeddings': [0.20963514, 0.39746657, 0.12019053, 0.6947492, 0.9535575, 0.5454552, 0.82360446, 0.21096309, 0.52323616, 0.8035404, 0.77824664, 0.80369574, 0.4914803, 0.8265614, 0.6145269, 0.80234545], 'pk': 0} search latency = 0.4476s === Start hybrid searching with `random > 0.5` === hit: id: 2998, distance: 0.0, entity: {'random': 0.9728033590489911}, random field: 0.9728033590489911 hit: id: 1831, distance: 0.6797959804534912, entity: {'random': 0.6331477114129169}, random field: 0.6331477114129169 hit: id: 678, distance: 0.7351570129394531, entity: {'random': 0.5195484662306603}, random field: 0.5195484662306603 hit: id: 2644, distance: 0.8620758056640625, entity: {'random': 0.9785952878381153}, random field: 0.9785952878381153 hit: id: 1960, distance: 0.9083120226860046, entity: {'random': 0.6376039340439571}, random field: 0.6376039340439571 hit: id: 106, distance: 0.9792704582214355, entity: {'random': 0.9679994241326673}, random field: 0.9679994241326673 search latency = 0.1232s Does collection hello_milvus_ntapnew_update2_sc2 exist in Milvus: True {'auto_id': True, 'description': 'hello_milvus_ntapnew_update2_sc2', 'fields': [{'name': 'pk', 'description': '', 'type': <DataType.INT64: 5>, 'is_primary': True, 'auto_id': True}, {'name': 'random', 'description': '', 'type': <DataType.DOUBLE: 11>}, {'name': 'var', 'description': '', 'type': <DataType.VARCHAR: 21>, 'params': {'max_length': 65535}}, {'name': 'embeddings', 'description': '', 'type': <DataType.FLOAT_VECTOR: 101>, 'params': {'dim': 16}}]}Basierend auf der obigen Validierung bietet die Integration von Kubernetes mit einer Vektordatenbank, wie durch die Bereitstellung eines Milvus-Clusters auf Kubernetes unter Verwendung eines NetApp -Speichercontrollers demonstriert, Kunden eine robuste, skalierbare und effiziente Lösung für die Verwaltung umfangreicher Datenvorgänge. Dieses Setup bietet Kunden die Möglichkeit, hochdimensionale Daten zu verarbeiten und komplexe Abfragen schnell und effizient auszuführen, was es zu einer idealen Lösung für Big-Data-Anwendungen und KI-Workloads macht. Die Verwendung von Persistent Volumes (PVs) für verschiedene Clusterkomponenten sowie die Erstellung eines einzelnen NFS-Volumes aus NetApp ONTAP gewährleisten eine optimale Ressourcennutzung und Datenverwaltung. Der Prozess der Überprüfung des Status von PersistentVolumeClaims (PVCs) und Pods sowie das Testen des Schreibens und Lesens von Daten bietet Kunden die Gewissheit zuverlässiger und konsistenter Datenvorgänge. Die Verwendung von ONTAP oder StorageGRID -Objektspeicher für Kundendaten verbessert die Datenzugänglichkeit und -sicherheit zusätzlich. Insgesamt bietet diese Konfiguration den Kunden eine robuste und leistungsstarke Datenverwaltungslösung, die sich nahtlos an ihren wachsenden Datenbedarf anpassen lässt.
-