פריסת מסד נתונים וקטורי של Qdrant ב-GKE

במדריך הזה נסביר איך לפרוס אשכול של מסד נתונים וקטורי Qdrant ב-Google Kubernetes Engine ‏ (GKE).

מסדי נתונים וקטוריים הם מאגרי נתונים שנועדו במיוחד לניהול ולחיפוש של אוספים גדולים של וקטורים רב-ממדיים. הווקטורים האלה מייצגים נתונים כמו טקסט, תמונות, אודיו, וידאו או כל נתון שאפשר לקודד באופן מספרי. בניגוד למסדי נתונים מסורתיים שמסתמכים על התאמות מדויקות, מסדי נתונים וקטוריים מתמחים במציאת פריטים דומים או בזיהוי דפוסים במערכי נתונים עצומים. המאפיינים האלה הופכים את Qdrant לבחירה מתאימה למגוון רחב של אפליקציות, כולל התאמה שמבוססת על רשתות נוירונים או על סמנטיקה, חיפוש עם היבטים ועוד. ‫Qdrant לא פועל רק כמסד נתונים של וקטורים, אלא גם כמנוע חיפוש של דמיון וקטורי.

המדריך הזה מיועד לאדמינים וארכיטקטים של פלטפורמות ענן, למהנדסי ML ולמומחי MLOps (DevOps) שרוצים לפרוס אשכולות של מסדי נתונים של Qdrant ב-GKE.

יתרונות

היתרונות של Qdrant:

  • מגוון רחב של ספריות לשפות תכנות שונות ו-API פתוח לשילוב עם שירותים אחרים.
  • מדרגיות אופקית ותמיכה בחלוקה (sharding) ובשכפול (replication) שמפשטות את המדרגיות והזמינות הגבוהה.
  • תמיכה בקונטיינרים וב-Kubernetes שמאפשרת פריסה וניהול בסביבות מודרניות מבוססות-ענן.
  • מטענים גמישים עם סינון מתקדם כדי להתאים את קריטריוני החיפוש בצורה מדויקת.
  • אפשרויות קוונטיזציה שונות ואופטימיזציות אחרות לצמצום עלויות התשתית ולשיפור הביצועים.

מטרות

במדריך הזה תלמדו איך:

  • תכנון ופריסה של תשתית GKE ל-Qdrant.
  • כדי להבטיח זמינות גבוהה של Qdrant, פורסים את האופרטור StatefulHA.
  • פורסים ומגדירים את אשכול Qdrant.
  • העלאה של מערך נתונים לדוגמה והרצת שאילתת חיפוש פשוטה.
  • איסוף מדדים והפעלת לוח בקרה.

ארכיטקטורת פריסה

הארכיטקטורה הזו מגדירה אשכול GKE עמיד בכשלים וניתן להרחבה עבור Qdrant בכמה אזורי זמינות, כדי להבטיח זמן פעולה וזמינות עם עדכונים מתגלגלים ושיבושים מינימליים. הוא כולל שימוש באופרטור StatefulHA לניהול יעיל של מעבר לגיבוי. מידע נוסף זמין במאמר אשכולות אזוריים.

דיאגרמת ארכיטקטורה

הדיאגרמה הבאה מציגה אשכול Qdrant שפועל בכמה צמתים ואזורים באשכול GKE:

ארכיטקטורת הפריסה של Qdrant

באדריכלות הזו, Qdrant StatefulSet נפרס על פני שלושה צמתים בשלושה אזורים שונים.

  • כדי לקבוע איך GKE יפיץ את ה-Pods בין הצמתים, צריך להגדיר את כללי הקרבה ואילוצי הפצה טופולוגיים הנדרשים של ה-Pods בקובץ הערכים של תרשים Helm.
  • אם אזור אחד נכשל, מערכת GKE מתזמנת מחדש את ה-Pods בצמתים חדשים על סמך ההגדרה המומלצת.

כדי לשמור את הנתונים, הארכיטקטורה במדריך הזה כוללת את המאפיינים הבאים:

  • הוא משתמש בדיסקי SSD אזוריים (StorageClass מותאם אישיתregional-pd) כדי לשמור את הנתונים. מומלץ להשתמש בדיסקי SSD אזוריים למסדי נתונים בגלל זמן האחזור הנמוך וערכי ה-IOPS הגבוהים שלהם.
  • כל הנתונים בדיסק משוכפלים בין אזורים ראשיים ומשניים באזור, וכך משפרים את הסבילות לכשלים פוטנציאליים באזור.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.

לפני שמתחילים

במדריך הזה משתמשים ב-Cloud Shell כדי להריץ פקודות. ‫Cloud Shell היא סביבת מעטפת לניהול משאבים שמתארחים ב- Google Cloud. הוא מגיע עם כלי שורת הפקודה Google Cloud CLI, ‏ kubectl,‏ Helm ו- Terraform שכבר מותקנים בו. אם אתם לא משתמשים ב-Cloud Shell, אתם צריכים להתקין את Google Cloud CLI.

  1. התקינו את ה-CLI של Google Cloud.

  2. הגדירו שה-CLI של gcloud ישתמש בזהות המאוחדת שלכם.

    איך נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת?

  3. כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה: 

    gcloud init

  4. יוצרים או בוחרים Google Cloud פרויקט.

    תפקידים שנדרשים כדי לבחור או ליצור פרויקט

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

    • יוצרים Google Cloud פרויקט:

      gcloud projects create PROJECT_ID

      מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.

    • בוחרים את הפרויקט שיצרתם: Google Cloud 

      gcloud config set project PROJECT_ID

      מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

  5. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

  6. מפעילים את ממשקי ה-API הבאים: מנהל המשאבים, Compute Engine,‏ GKE,‏ IAM Service Account Credentials ו-Backup for GKE:

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים 

    gcloud services enable cloudresourcemanager.googleapis.com compute.googleapis.com container.googleapis.com iamcredentials.googleapis.com gkebackup.googleapis.com

  7. מעניקים תפקידים לחשבון המשתמש. מריצים את הפקודה הבאה לכל אחד מהתפקידים הבאים ב-IAM: roles/storage.objectViewer, roles/container.admin, roles/iam.serviceAccountAdmin, roles/compute.admin, roles/gkebackup.admin, roles/monitoring.viewer 

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE

    מחליפים את מה שכתוב בשדות הבאים:

מגדירים את הסביבה

כדי להגדיר את הסביבה באמצעות Cloud Shell:

  1. מגדירים משתני סביבה לפרויקט, לאזור ולקידומת של משאב אשכול Kubernetes:

    לצורך המדריך הזה, משתמשים באזור us-central1 כדי ליצור את משאבי הפריסה.

    export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=qdrant
export REGION=us-central1
    • מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

  2. בודקים את הגרסה של Helm:

    helm version

    אם הגרסה ישנה יותר מ-3.13, צריך לעדכן אותה:

    curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

  3. משכפלים את מאגר המקורות של הקוד לדוגמה מ-GitHub:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

  4. כדי להתחיל ליצור משאבי פריסה, עוברים לספרייה qdrant:

    cd kubernetes-engine-samples/databases/qdrant

יצירת תשתית האשכול

בקטע הזה מריצים סקריפט Terraform כדי ליצור אשכול GKE פרטי, זמין מאוד ואזורי, כדי לפרוס את מסד הנתונים של Qdrant.

אפשר לבחור לפרוס את Qdrant באמצעות אשכול רגיל או אשכול במצב Autopilot. לכל אחד מהם יש יתרונות משלו ומודלים שונים של תמחור.

טייס אוטומטי

בתרשים הבא מוצג אשכול GKE אזורי של Autopilot שנפרס בשלושה אזורים שונים.

אשכול GKE Autopilot

כדי לפרוס את תשתית האשכול, מריצים את הפקודות הבאות ב-Cloud Shell:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

המשתנים הבאים מוחלפים בזמן הריצה:

  • ‫GOOGLE_OAUTH_ACCESS_TOKEN: הוחלף באסימון גישה שאוחזר על ידי הפקודה gcloud auth print-access-token לאימות אינטראקציות עם Google Cloud APIs שונים
  • ‫PROJECT_ID,‏ REGION ו-KUBERNETES_CLUSTER_PREFIX הם משתני הסביבה שמוגדרים בקטע הגדרת הסביבה ומוקצים למשתנים הרלוונטיים החדשים עבור אשכול Autopilot שאתם יוצרים.

כשמופיעה בקשה, כותבים yes.

הפלט אמור להיראות כך:

...
Apply complete! Resources: 9 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials qdrant-cluster --region us-central1"

‫Terraform יוצר את המשאבים הבאים:

  • רשת VPC מותאמת אישית ותת-רשת פרטית לצמתים של Kubernetes.
  • ‫Cloud Router כדי לגשת לאינטרנט דרך תרגום כתובות רשת (NAT).
  • אשכול GKE פרטי באזור us-central1.
  • ServiceAccount עם הרשאות רישום ביומן ומעקב עבור האשכול.
  • הגדרת השירות המנוהל של Google Cloud ל-Prometheus לצורך מעקב והתראות לגבי אשכולות.

רגילה

בתרשים הבא מוצג אשכול GKE פרטי רגיל שנפרס בשלושה אזורים שונים.

אשכול GKE Standard

כדי לפרוס את תשתית האשכול, מריצים את הפקודות הבאות ב-Cloud Shell:

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

המשתנים הבאים מוחלפים בזמן הריצה:

  • ‫GOOGLE_OAUTH_ACCESS_TOKEN מוחלף באסימון גישה שאוחזר באמצעות הפקודה gcloud auth print-access-token כדי לאמת אינטראקציות עם ממשקי Google Cloud API שונים.
  • ‫PROJECT_ID, ‏REGION ו-KUBERNETES_CLUSTER_PREFIX הם משתני הסביבה שמוגדרים בקטע הגדרת הסביבה ומוקצים למשתנים הרלוונטיים החדשים עבור אשכול Standard שאתם יוצרים.

כשמופיעה בקשה, כותבים yes. יכול להיות שיחלפו כמה דקות עד שהפקודות האלה יסתיימו והאשכול יציג סטטוס מוכן.

הפלט אמור להיראות כך:

...
Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:

kubectl_connection_command = "gcloud container clusters get-credentials qdrant-cluster --region us-central1"

‫Terraform יוצר את המשאבים הבאים:

  • רשת VPC מותאמת אישית ותת-רשת פרטית לצמתים של Kubernetes.
  • ‫Cloud Router כדי לגשת לאינטרנט דרך תרגום כתובות רשת (NAT).
  • אשכול GKE פרטי באזור us-central1 עם התאמה אוטומטית לעומס (node אחד עד שני צמתים לכל אזור).
  • ServiceAccount עם הרשאות רישום ביומן ומעקב עבור האשכול.
  • הגדרת השירות המנוהל של Google Cloud ל-Prometheus לניטור של אשכולות ולהתראות.

התחברות לאשכול

מגדירים את kubectl כך שיאחזר פרטי כניסה ויצור קשר עם אשכול GKE החדש:

gcloud container clusters get-credentials \
    ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}

פריסת מסד הנתונים של Qdrant באשכול

במדריך הזה תפרסו את מסד הנתונים Qdrant (במצב מבוזר) ואת אופרטור ה-HA עם שמירת מצב באשכול GKE באמצעות תרשים Helm.

הפריסה יוצרת אשכול GKE עם ההגדרות הבאות:

  • שלוש רפליקות של צמתי Qdrant.
  • הגדרנו סבילות, קשרי גומלין בין צמתים ומגבלות על פיזור טופולוגי כדי להבטיח פיזור נכון בין צמתי Kubernetes. השיטה הזו מתבססת על מאגרי הצמתים ואזורי הזמינות השונים.
  • נפח אחסון של RePD עם סוג הדיסק SSD מוקצה לאחסון נתונים.
  • אופרטור HA עם שמירת מצב משמש לניהול תהליכי יתירות כשל ולשמירה על זמינות גבוהה. ‫StatefulSet הוא בקר Kubernetes ששומר על זהות ייחודית ומתמשכת לכל אחד מה-Pods שלו.
  • לצורך אימות, מסד הנתונים יוצר סוד של Kubernetes שמכיל את מפתח ה-API.

כדי להשתמש בתרשים Helm לפריסת מסד נתונים של Qdrant, פועלים לפי השלבים הבאים:

  1. מפעילים את התוסף StatefulHA:

    טייס אוטומטי

    ‫GKE מפעיל באופן אוטומטי את התוסף StatefulHA כשיוצרים את האשכול.

    רגילה

    מריצים את הפקודה הבאה:

    gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
    --project=${PROJECT_ID} \
    --location=${REGION} \
    --update-addons=StatefulHA=ENABLED

    יכול להיות שיחלפו 15 דקות עד שהפקודה תושלם ועד שהאשכול יציג סטטוס מוכן.

  2. כדי לפרוס את מאגר התרשימים של Qdrant database Helm ב-אשכול GKE, צריך להוסיף אותו קודם:

    helm repo add qdrant https://qdrant.github.io/qdrant-helm

  3. יוצרים מרחב שמות qdrant למסד הנתונים:

    kubectl create ns qdrant

  4. מחילים את קובץ המניפסט כדי ליצור דיסק SSD אזורי לאחסון מתמיד StorageClass:

    kubectl apply -n qdrant -f manifests/01-regional-pd/regional-pd.yaml

    המניפסט regional-pd.yaml מתאר את דיסק ה-SSD המתמיד StorageClass:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
allowVolumeExpansion: true
metadata:
  name: ha-regional
parameters:
  replication-type: regional-pd
  type: pd-ssd
  availability-class: regional-hard-failover
provisioner: pd.csi.storage.gke.io
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

  5. פורסים configmap של Kubernetes עם הגדרת קובץ עזר metrics ואשכול Qdrant באמצעות Helm:

    kubectl apply -n qdrant -f manifests/03-prometheus-metrics/metrics-cm.yaml
helm install qdrant-database qdrant/qdrant -n qdrant \
-f manifests/02-values-file/values.yaml

    במניפסט metrics-cm.yaml מתואר ה-sidecar‏ metrics ConfigMap:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  default.conf.template: |
    server {
      listen 80;
      location / {
        proxy_pass http://localhost:6333/metrics;
        proxy_http_version 1.1;
        proxy_set_header Host $http_host;
        proxy_set_header api-key ${QDRANT_APIKEY};
        proxy_set_header X-Forwarded-For $remote_addr;
      }
    }

    values.yaml קובץ המניפסט מתאר את הגדרת אשכול Qdrant :

    replicaCount: 3

config:
  service:
    enable_tls: false
  cluster:
    enabled: true
  storage:
    optimizers:
      deleted_threshold: 0.5
      vacuum_min_vector_number: 1500
      default_segment_number: 2
      max_segment_size_kb: null
      memmap_threshold_kb: null
      indexing_threshold_kb: 25000
      flush_interval_sec: 5
      max_optimization_threads: 1

livenessProbe:
  enabled: true
  initialDelaySeconds: 60

resources:
  limits:
    cpu: "2"
    memory: 4Gi
  requests:
    cpu: "1"
    memory: 4Gi

tolerations:
  - key: "app.stateful/component"
    operator: "Equal"
    value: "qdrant"
    effect: NoSchedule

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        - key: "app.stateful/component"
          operator: In
          values:
          - "qdrant"

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app.kubernetes.io/name: qdrant
        app.kubernetes.io/instance: qdrant

podDisruptionBudget:
  enabled: true
  maxUnavailable: 1

persistence:
  accessModes: ["ReadWriteOnce"]
  size: 10Gi
  storageClassName: ha-regional

apiKey: true

sidecarContainers:
  - name: metrics
    image: nginx:1.29
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
    - containerPort: 80
    env:
    - name: QDRANT_APIKEY 
      valueFrom:
        secretKeyRef:
          name: qdrant-database-apikey          
          key: api-key
    volumeMounts:
        - name: nginx-conf
          mountPath: /etc/nginx/templates/default.conf.template
          subPath: default.conf.template
          readOnly: true
additionalVolumes:
  - name: nginx-conf
    configMap:
      name: nginx-conf
      items:
        - key: default.conf.template
          path: default.conf.template

    ההגדרה הזו מפעילה את מצב האשכול, ומאפשרת להגדיר אשכול Qdrant זמין ומופץ.

  6. הוספת תווית ל-Qdrant statefulset:

    kubectl label statefulset qdrant-database examples.ai.gke.io/source=qdrant-guide -n qdrant

  7. פריסת מאזן עומסים פנימי כדי לגשת למסד הנתונים של Qdrant שפועל באותו VPC כמו אשכול GKE:

    kubectl apply -n qdrant -f manifests/02-values-file/ilb.yaml

    במניפסט ilb.yaml מתואר שירות LoadBalancer:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    #cloud.google.com/neg: '{"ingress": true}'
    networking.gke.io/load-balancer-type: "Internal"
  labels:
    app.kubernetes.io/name: qdrant
  name: qdrant-ilb
spec:
  ports:
  - name: http
    port: 6333
    protocol: TCP
    targetPort: 6333
  - name: grpc
    port: 6334
    protocol: TCP
    targetPort: 6334
  selector:
    app: qdrant
    app.kubernetes.io/instance: qdrant-database
  type: LoadBalancer

  8. בודקים את סטטוס הפריסה:

    helm ls -n qdrant

    אם מסד הנתונים qdrant נפרס בהצלחה, הפלט אמור להיראות כך:

    NAME    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
qdrant-database  qdrant          1               2024-02-06 20:21:15.737307567 +0000 UTC deployed        qdrant-0.7.6    v1.7.4

  9. מחכים ש-GKE יתחיל את עומסי העבודה הנדרשים:

    kubectl wait pods -l app.kubernetes.io/instance=qdrant-database --for condition=Ready --timeout=300s -n qdrant

    יכול להיות שיחלפו כמה דקות עד שהפקודה הזו תסתיים בהצלחה.

  10. אחרי ש-GKE מפעיל את עומסי העבודה, מוודאים ש-GKE יצר את עומסי העבודה של Qdrant:

    kubectl get pod,svc,statefulset,pdb,secret -n qdrant

  11. מפעילים את משאב HighAvailabilityApplication (HAA) עבור Qdrant:

    kubectl apply -n qdrant -f manifests/01-regional-pd/ha-app.yaml

    המניפסט ha-app.yaml מתאר את המשאב HighAvailabilityApplication:

    kind: HighAvailabilityApplication
apiVersion: ha.gke.io/v1
metadata:
  name: qdrant-database
  namespace: qdrant
spec:
  resourceSelection:
    resourceKind: StatefulSet
  policy:
    storageSettings:
      requireRegionalStorage: true
    failoverSettings:
      forceDeleteStrategy: AfterNodeUnreachable
      afterNodeUnreachable:
        afterNodeUnreachableSeconds: 20 # 60 seconds total

    משאבי GKE הבאים נוצרים עבור אשכול Qdrant:

    • ‫Qdrant StatefulSet ששולט בשלושה עותקים של Pod.
    • ‫A PodDisruptionBudget, כדי להבטיח שיהיה לכל היותר עותק רפליקה אחד שלא זמין.
    • שירות qdrant-database, שחושף את יציאת Qdrant לחיבורים נכנסים ולשכפול בין צמתים.
    • השירות qdrant-database-headless, שמספק את רשימת ה-Pods של Qdrant שפועלים.
    • qdrant-database-apikey Secret, שמאפשר חיבור מאובטח למסד הנתונים.
    • ‫Pod של אופרטור HA עם שמירת מצב ומשאב HighlyAvailableApplication, שמנטרים באופן פעיל את אפליקציית Qdrant. המשאב HighlyAvailableApplication מגדיר כללי יתירות כשל שיוחלו על Qdrant.

  12. כדי לבדוק אם כללי המעבר לגיבוי חלים, מתארים את המשאב ומאשרים את Status: Message: Application is protected.

    kubectl describe highavailabilityapplication qdrant-database -n qdrant

    הפלט אמור להיראות כך:

    Status:
Conditions:
    Last Transition Time:  2023-11-30T09:54:52Z
    Message:               Application is protected
    Observed Generation:   1
    Reason:                ApplicationProtected
    Status:                True
    Type:                  Protected

הרצת שאילתות באמצעות מחברת Vertex AI Colab Enterprise

‫Qdrant מארגן וקטורים ומטענים ייעודיים (payloads) באוספים. הטמעת וקטורים היא טכניקה שמייצגת מילים או ישויות כווקטורים מספריים, תוך שמירה על הקשרים הסמנטיים שלהם. זה חשוב לחיפושים של דמיון, כי זה מאפשר למצוא דמיון על סמך משמעות ולא על סמך התאמות מדויקות. כך אפשר לשפר את היעילות והדיוק של משימות כמו חיפוש ומערכות המלצה.

בקטע הזה מוסבר איך מעלים וקטורים לאוסף חדש של Qdrant ואיך מריצים שאילתות חיפוש.

בדוגמה הזו, משתמשים במערך נתונים מקובץ CSV שמכיל רשימה של ספרים בז'אנרים שונים. יוצרים מחברת Colab Enterprise כדי לבצע שאילתת חיפוש במסד הנתונים של Qdrant.

מידע נוסף על Vertex AI Colab Enterprise זמין במאמרי העזרה של Colab Enterprise.

יצירת תבנית בזמן ריצה

כדי ליצור תבנית של סביבת זמן ריצה ב-Colab Enterprise:

  1. במסוף Google Cloud , עוברים לדף Runtime Templates של Colab Enterprise ומוודאים שהפרויקט שלכם נבחר:

    מעבר אל Runtime Templates

  2. לוחצים על תבנית חדשה. מופיע הדף יצירת תבנית חדשה של זמן ריצה.

  3. בקטע Runtime basics:

    • בשדה שם מוצג, מזינים qdrant-connect.
    • ברשימה הנפתחת אזור, בוחרים באפשרות us-central1. זהו אותו אזור כמו באשכול GKE.

  4. בקטע Configure compute (הגדרת מחשוב):

    • ברשימה הנפתחת סוג המכונה בוחרים באפשרות e2-standard-2.
    • בשדה גודל הדיסק, מזינים 30.

  5. בקטע רשתות ואבטחה:

    • ברשימה הנפתחת רשת, בוחרים את הרשת שבה נמצא אשכול GKE.
    • ברשימה הנפתחת Subnetwork (רשת משנה), בוחרים את רשת המשנה המתאימה.
    • מבטלים את הסימון בתיבת הסימון הפעלת גישה ציבורית לאינטרנט.

  6. כדי לסיים את יצירת התבנית בזמן ריצה, לוחצים על יצירה. התבנית של סביבת זמן הריצה מופיעה ברשימה בכרטיסייה תבניות של סביבת זמן הריצה.

יצירת סביבת ריצה

כדי ליצור סביבת זמן ריצה ב-Colab Enterprise:

  1. ברשימת תבניות זמן הריצה של התבנית שיצרתם, בעמודה פעולות, לוחצים על ואז על יצירת זמן ריצה. מופיעה החלונית Create Vertex AI Runtime.

  2. כדי ליצור סביבת ריצה על סמך התבנית, לוחצים על יצירה.

  3. בכרטיסייה Runtimes (זמני ריצה) שנפתחת, מחכים שהסטטוס ישתנה ל-Healthy (תקין).

ייבוא המחברת

כדי לייבא את ה-notebook ב-Colab Enterprise:

  1. עוברים לכרטיסייה המחברות שלי ולוחצים על ייבוא. החלונית Import notebooks תופיע.

  2. בקטע מקור לייבוא, בוחרים באפשרות כתובת URL.

  3. בקטע כתובות URL של מחברות, מזינים את הקישור הבא:

    https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes-engine-samples/refs/heads/main/databases/qdrant/manifests/04-notebook/vector-database.ipynb

  4. לוחצים על Import.

התחברות לסביבת זמן הריצה והרצת שאילתות

כדי להתחבר לסביבת זמן הריצה ולהריץ שאילתות:

  1. במחברת, ליד הלחצן Connect (התחברות), לוחצים על Additional connection options (אפשרויות חיבור נוספות). מופיעה החלונית Connect to Vertex AI Runtime (התחברות לסביבת זמן ריצה של Vertex AI).

  2. בוחרים באפשרות Connect to a runtime (התחברות לסביבת זמן ריצה) ואז באפשרות Connect to an existing Runtime (התחברות לסביבת זמן ריצה קיימת).

  3. בוחרים את זמן הריצה שהפעלתם ולוחצים על Connect (חיבור).

  4. כדי להריץ את התאים ב-notebook, לוחצים על הלחצן Run cell לצד כל תא קוד.

הנוטבוק מכיל תאי קוד וטקסט שמתאר כל בלוק קוד. כשמריצים תא קוד, הפקודות שבו מופעלות ומוצג פלט. אפשר להריץ את התאים לפי הסדר, או להריץ תאים ספציפיים לפי הצורך.

הצגת מדדי Prometheus לאשכול

אשכול GKE מוגדר עם השירות המנוהל של Google Cloud ל-Prometheus, שמאפשר איסוף מדדים בפורמט Prometheus. השירות הזה מספק פתרון מנוהל מלא למעקב ולהתראות, ומאפשר איסוף, אחסון וניתוח של מדדים מהאשכול ומהאפליקציות שלו.

בתרשים הבא אפשר לראות איך Prometheus אוסף מדדים לגבי האשכול:

אוסף מדדים של Prometheus

האשכול הפרטי של GKE בתרשים מכיל את הרכיבים הבאים:

  • ‫Qdrant Pods שחושפים מדדים בנתיב / ובפורט 80. המדדים האלה מסופקים על ידי קונטיינר ה-sidecar שנקרא metrics.
  • אוספי נתונים מבוססי Prometheus שמעבדים את המדדים מ-Qdrant Pods.
  • משאב PodMonitoring ששולח את המדדים אל Cloud Monitoring.

כדי לייצא את המדדים ולראות אותם:

  1. יוצרים את משאב PodMonitoring כדי לגרד מדדים לפי labelSelector:

    kubectl apply -n qdrant -f manifests/03-prometheus-metrics/pod-monitoring.yaml

    המניפסט pod-monitoring.yaml מתאר את המשאב PodMonitoring:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: qdrant
spec:
  selector:
    matchLabels:
      app: qdrant
      app.kubernetes.io/instance: qdrant-database
  endpoints:
  - port: 80
    interval: 30s
    path: /

  2. יוצרים לוח בקרה של Cloud Monitoring עם ההגדרות שמוגדרות ב-dashboard.json :

    gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file monitoring/dashboard.json

  3. אחרי שהפקודה מורצת בהצלחה, עוברים אל לוחות הבקרה ב-Cloud Monitoring:

    מעבר לסקירה הכללית של מרכזי השליטה

  4. ברשימת לוחות הבקרה, פותחים את לוח הבקרה Qdrant Overview. יכול להיות שיחלפו דקה או שתיים עד שהמדדים ייאספו ויוצגו.

    בלוח הבקרה מוצג מספר של מדדי מפתח:

    • אוספים
    • וקטורים מוטמעים
    • פעולות בהמתנה
    • צמתים פעילים

גיבוי של הגדרת האשכול

התכונה גיבוי ל-GKE מאפשרת לתזמן גיבויים קבועים של כל ההגדרות של אשכול GKE, כולל עומסי העבודה שנפרסו והנתונים שלהם.

במדריך הזה מוגדרת תוכנית גיבוי לאשכול GKE כדי לבצע גיבויים של כל עומסי העבודה, כולל Secrets ו-Volumes, כל יום בשעה 3:00. כדי להבטיח ניהול יעיל של האחסון, גיבויים בני יותר משלושה ימים יימחקו באופן אוטומטי.

כדי להגדיר תוכניות גיבוי, מבצעים את השלבים הבאים:

  1. מפעילים את התכונה 'גיבוי ל-GKE' באשכול:

    gcloud container clusters update ${KUBERNETES_CLUSTER_PREFIX}-cluster \
--project=${PROJECT_ID} \
--location=${REGION} \
--update-addons=BackupRestore=ENABLED

  2. יוצרים תוכנית גיבוי עם תזמון יומי לכל מרחבי השמות באשכול:

    gcloud beta container backup-restore backup-plans create ${KUBERNETES_CLUSTER_PREFIX}-cluster-backup \
--project=${PROJECT_ID} \
--location=${REGION} \
--cluster="projects/${PROJECT_ID}/locations/${REGION}/clusters/${KUBERNETES_CLUSTER_PREFIX}-cluster" \
--all-namespaces \
--include-secrets \
--include-volume-data \
--cron-schedule="0 3 * * *" \
--backup-retain-days=3

    הפקודה משתמשת במשתני הסביבה הרלוונטיים בזמן הריצה.

    הפורמט של שם האשכול הוא יחסי לפרויקט ולאזור שלכם, באופן הבא:

    projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME

    כשמופיעה הבקשה, מקלידים y.הפלט אמור להיראות כך:

    Create request issued for: [qdrant-cluster-backup]
Waiting for operation [projects/PROJECT_ID/locations/us-central1/operations/operation-1706528750815-610142ffdc9ac-71be4a05-f61c99fc] to complete...⠹

    יכול להיות שיחלפו כמה דקות עד שהפעולה תושלם בהצלחה. אחרי שההפעלה תושלם, הפלט ייראה כך:

    Created backup plan [qdrant-cluster-backup].

  3. תוכנית הגיבוי החדשה qdrant-cluster-backup מופיעה במסוף Backup for GKE.

    מעבר לגיבוי ל-GKE

אם רוצים לשחזר את הגדרות הגיבוי שנשמרו, אפשר לעיין במאמר בנושא שחזור גיבוי.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים, או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

מחיקת הפרויקט

הדרך הכי קלה להימנע מחיוב היא למחוק את הפרויקט שיצרתם בשביל המדריך הזה.

כדי למחוק Google Cloud פרויקט:

gcloud projects delete PROJECT_ID

אם מחקתם את הפרויקט, סיימתם את הניקוי. אם לא מחקתם את הפרויקט, צריך למחוק את המשאבים בנפרד.

מחיקת משאבים בודדים

  1. מגדירים משתני סביבה.

    export PROJECT_ID=${PROJECT_ID}
export KUBERNETES_CLUSTER_PREFIX=qdrant
export REGION=us-central1

  2. מריצים את הפקודה terraform destroy:

    export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform  -chdir=terraform/FOLDER destroy \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

    מחליפים את FOLDER ב-gke-autopilot או ב-gke-standard, בהתאם לסוג אשכול GKE שיצרתם.

    כשמופיעה בקשה, כותבים yes.

  3. חיפוש כל הדיסקים שלא מצורפים:

    export disk_list=$(gcloud compute disks list --filter="-users:* AND labels.name=${KUBERNETES_CLUSTER_PREFIX}-cluster" --format "value[separator=|](name,region)")

  4. מוחקים את הדיסקים:

    for i in $disk_list; do
 disk_name=$(echo $i| cut -d'|' -f1)
 disk_region=$(echo $i| cut -d'|' -f2|sed 's|.*/||')
 echo "Deleting $disk_name"
 gcloud compute disks delete $disk_name --region $disk_region --quiet
done

  5. מחיקת המאגר ב-GitHub:

    rm -r ~/kubernetes-engine-samples/

המאמרים הבאים