റൂക്ക് ചെയ്യണോ വേണ്ടയോ - അതാണ് ചോദ്യം

ഈ മാസത്തിന്റെ തുടക്കത്തിൽ, മെയ് 3 ന്, “കുബർനെറ്റസിലെ വിതരണം ചെയ്ത ഡാറ്റ സംഭരണത്തിനുള്ള മാനേജ്മെന്റ് സിസ്റ്റത്തിന്റെ” ഒരു പ്രധാന റിലീസ് പ്രഖ്യാപിച്ചു - റൂക്ക് 1.0.0. ഒരു വർഷം മുമ്പ് ഞങ്ങൾ ഇതിനകം തന്നെ പ്രസിദ്ധീകരിച്ചു റൂക്കിന്റെ പൊതുവായ അവലോകനം. എന്നിട്ട് ഞങ്ങളോട് അവന്റെ അനുഭവത്തെക്കുറിച്ച് സംസാരിക്കാൻ ആവശ്യപ്പെട്ടു പ്രായോഗികമായി ഉപയോഗിക്കുക - ഇപ്പോൾ, പ്രോജക്റ്റിന്റെ ചരിത്രത്തിലെ അത്തരമൊരു സുപ്രധാന നാഴികക്കല്ലിന്റെ സമയത്ത്, ഞങ്ങളുടെ ശേഖരിച്ച ഇംപ്രഷനുകൾ പങ്കിടുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട്.

ചുരുക്കത്തിൽ, റൂക്ക് ഒരു സെറ്റാണ് ഓപ്പറേറ്റർമാർ Ceph, EdgeFS, Minio, Cassandra, CockroachDB തുടങ്ങിയ ഡാറ്റാ സ്റ്റോറേജ് സൊല്യൂഷനുകളുടെ വിന്യാസം, മാനേജ്മെന്റ്, ഓട്ടോമാറ്റിക് റിക്കവറി എന്നിവയുടെ പൂർണ്ണ നിയന്ത്രണം ഏറ്റെടുക്കുന്ന Kubernetes-ന്.

ഇപ്പോൾ ഏറ്റവും വികസിത (ഒപ്പം ഒരേയൊരു в സ്ഥിരതയുള്ള ഘട്ടം) ആണ് പരിഹാരം റൂക്ക്-സെഫ്-ഓപ്പറേറ്റർ.

അഭിപായപ്പെടുക: Ceph-മായി ബന്ധപ്പെട്ട Rook 1.0.0 പതിപ്പിലെ പ്രധാന മാറ്റങ്ങളിൽ, Ceph Nautilus-നുള്ള പിന്തുണയും CephFS അല്ലെങ്കിൽ RGW ബക്കറ്റുകൾക്കായി NFS ഉപയോഗിക്കാനുള്ള കഴിവും നമുക്ക് ശ്രദ്ധിക്കാം. മറ്റുള്ളവയിൽ വേറിട്ടുനിൽക്കുന്നത് ബീറ്റ ലെവലിലേക്കുള്ള EdgeFS പിന്തുണയുടെ പക്വതയാണ്.

അതിനാൽ, ഈ ലേഖനത്തിൽ ഞങ്ങൾ:

• ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ സെഫിനെ വിന്യസിക്കാൻ റൂക്ക് ഉപയോഗിക്കുന്നതിന്റെ ഗുണങ്ങൾ എന്തൊക്കെയാണെന്ന ചോദ്യത്തിന് ഉത്തരം നൽകാം;
• നിർമ്മാണത്തിൽ റൂക്ക് ഉപയോഗിക്കുന്നതിന്റെ അനുഭവവും ഇംപ്രഷനുകളും ഞങ്ങൾ പങ്കിടും;
• എന്തുകൊണ്ടാണ് ഞങ്ങൾ റൂക്കിനോട് “അതെ!” എന്ന് പറയുന്നതെന്നും അവനുവേണ്ടിയുള്ള ഞങ്ങളുടെ പദ്ധതികളെക്കുറിച്ചും പറയാം.

പൊതുവായ ആശയങ്ങളും സിദ്ധാന്തവും ഉപയോഗിച്ച് നമുക്ക് ആരംഭിക്കാം.

"എനിക്ക് ഒരു റൂക്കിന്റെ പ്രയോജനമുണ്ട്!" (അജ്ഞാത ചെസ്സ് കളിക്കാരൻ)

റൂക്കിന്റെ പ്രധാന നേട്ടങ്ങളിലൊന്ന്, ഡാറ്റ സ്റ്റോറുകളുമായുള്ള ആശയവിനിമയം കുബർനെറ്റസ് മെക്കാനിസങ്ങളിലൂടെയാണ് നടത്തുന്നത്. ഇതിനർത്ഥം, ഷീറ്റിൽ നിന്ന് കൺസോളിലേക്ക് Ceph കോൺഫിഗർ ചെയ്യുന്നതിന് നിങ്ങൾ ഇനി കമാൻഡുകൾ പകർത്തേണ്ടതില്ല എന്നാണ്.

— നിങ്ങൾക്ക് CephFS ഒരു ക്ലസ്റ്ററിൽ വിന്യസിക്കണോ? ഒരു YAML ഫയൽ എഴുതുക!
- എന്ത്? നിങ്ങൾക്ക് S3 API ഉള്ള ഒരു ഒബ്‌ജക്റ്റ് സ്റ്റോറും വിന്യസിക്കണോ? രണ്ടാമത്തെ YAML ഫയൽ എഴുതുക!

ഒരു സാധാരണ ഓപ്പറേറ്ററുടെ എല്ലാ നിയമങ്ങൾക്കും അനുസരിച്ചാണ് റൂക്ക് സൃഷ്ടിച്ചിരിക്കുന്നത്. ഉപയോഗിച്ച് അവനുമായുള്ള ഇടപെടൽ സംഭവിക്കുന്നു CRD (കസ്റ്റം റിസോഴ്സ് നിർവചനങ്ങൾ), അതിൽ നമുക്ക് ആവശ്യമായ സെഫ് എന്റിറ്റികളുടെ സവിശേഷതകൾ വിവരിക്കുന്നു (ഇത് സുസ്ഥിരമായ നടപ്പാക്കൽ മാത്രമായതിനാൽ, ഡിഫോൾട്ടായി ഈ ലേഖനം സെഫിനെക്കുറിച്ച് സംസാരിക്കും, മറ്റുവിധത്തിൽ വ്യക്തമായി പറഞ്ഞില്ലെങ്കിൽ). നിർദ്ദിഷ്ട പാരാമീറ്ററുകൾ അനുസരിച്ച്, കോൺഫിഗറേഷന് ആവശ്യമായ കമാൻഡുകൾ ഓപ്പറേറ്റർ സ്വയമേവ നടപ്പിലാക്കും.

ഒരു ഒബ്ജക്റ്റ് സ്റ്റോർ സൃഷ്ടിക്കുന്നതിനുള്ള ഉദാഹരണം ഉപയോഗിച്ച് നമുക്ക് പ്രത്യേകതകൾ നോക്കാം, അല്ലെങ്കിൽ - CephObjectStoreUser.

apiVersion: ceph.rook.io/v1
kind: CephObjectStore
metadata:
  name: {{ .Values.s3.crdName }}
  namespace: kube-rook
spec:
  metadataPool:
    failureDomain: host
    replicated:
      size: 3
  dataPool:
    failureDomain: host
    erasureCoded:
      dataChunks: 2
      codingChunks: 1
  gateway:
    type: s3
    sslCertificateRef:
    port: 80
    securePort:
    instances: 1
    allNodes: false
---
apiVersion: ceph.rook.io/v1
kind: CephObjectStoreUser
metadata:
  name: {{ .Values.s3.crdName }}
  namespace: kube-rook
spec:
  store: {{ .Values.s3.crdName }}
  displayName: {{ .Values.s3.username }}

ലിസ്റ്റിംഗിൽ സൂചിപ്പിച്ചിരിക്കുന്ന പാരാമീറ്ററുകൾ തികച്ചും സ്റ്റാൻഡേർഡ് ആണ്, മാത്രമല്ല അഭിപ്രായങ്ങൾ ആവശ്യമില്ല, പക്ഷേ ടെംപ്ലേറ്റ് വേരിയബിളുകൾക്കായി നീക്കിവച്ചിരിക്കുന്നവയിൽ പ്രത്യേക ശ്രദ്ധ നൽകുന്നത് മൂല്യവത്താണ്.

ഒരു YAML ഫയലിലൂടെ ഞങ്ങൾ ഉറവിടങ്ങൾ "ഓർഡർ" ചെയ്യുന്നു എന്ന വസ്തുതയിലേക്കാണ് ജോലിയുടെ പൊതുവായ സ്കീം വരുന്നത്, അതിനായി ഓപ്പറേറ്റർ ആവശ്യമായ കമാൻഡുകൾ എക്സിക്യൂട്ട് ചെയ്യുകയും ഞങ്ങൾക്ക് കൂടുതൽ പ്രവർത്തിക്കാൻ കഴിയുന്ന ഒരു "യഥാർത്ഥമല്ലാത്ത" രഹസ്യം തിരികെ നൽകുകയും ചെയ്യുന്നു. (താഴെ നോക്കുക). മുകളിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന വേരിയബിളുകളിൽ നിന്ന്, കമാൻഡും രഹസ്യ നാമവും കംപൈൽ ചെയ്യപ്പെടും.

ഇത് ഏതുതരം ടീമാണ്? ഒബ്ജക്റ്റ് സ്റ്റോറേജിനായി ഒരു ഉപയോക്താവിനെ സൃഷ്ടിക്കുമ്പോൾ, പോഡിനുള്ളിലെ റൂക്ക് ഓപ്പറേറ്റർ ഇനിപ്പറയുന്നവ ചെയ്യും:

radosgw-admin user create --uid="rook-user" --display-name="{{ .Values.s3.username }}"

ഈ കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുന്നതിന്റെ ഫലം ഒരു JSON ഘടനയായിരിക്കും:

{
    "user_id": "rook-user",
    "display_name": "{{ .Values.s3.username }}",
    "keys": [
        {
           "user": "rook-user",
           "access_key": "NRWGT19TWMYOB1YDBV1Y",
           "secret_key": "gr1VEGIV7rxcP3xvXDFCo4UDwwl2YoNrmtRlIAty"
        }
    ],
    ...
}

Keys - S3 API വഴി ഒബ്‌ജക്റ്റ് സ്റ്റോറേജ് ആക്‌സസ് ചെയ്യാൻ ഭാവിയിൽ എന്ത് ആപ്ലിക്കേഷനുകൾ ആവശ്യമാണ്. റൂക്ക് ഓപ്പറേറ്റർ അവരെ ദയാപൂർവം തിരഞ്ഞെടുത്ത് പേരിനൊപ്പം ഒരു രഹസ്യ രൂപത്തിൽ അവന്റെ നെയിംസ്‌പെയ്‌സിൽ ഇടുന്നു. rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}.

ഈ രഹസ്യത്തിൽ നിന്നുള്ള ഡാറ്റ ഉപയോഗിക്കുന്നതിന്, പരിസ്ഥിതി വേരിയബിളുകളായി കണ്ടെയ്‌നറിലേക്ക് ചേർക്കുക. ഒരു ഉദാഹരണമായി, ജോലിയ്‌ക്കായി ഞാൻ ഒരു ടെംപ്ലേറ്റ് നൽകും, അതിൽ ഓരോ ഉപയോക്തൃ പരിതസ്ഥിതിക്കും ഞങ്ങൾ സ്വയമേവ ബക്കറ്റുകൾ സൃഷ്‌ടിക്കുന്നു:

{{- range $bucket := $.Values.s3.bucketNames }}
apiVersion: batch/v1
kind: Job
metadata:
  name: create-{{ $bucket }}-bucket-job
  annotations:
    "helm.sh/hook": post-install
    "helm.sh/hook-weight": "2"
spec:
  template:
    metadata:
      name: create-{{ $bucket }}-bucket-job
    spec:
      restartPolicy: Never
      initContainers:
      - name: waitdns
        image: alpine:3.6
        command: ["/bin/sh", "-c", "while ! getent ahostsv4 rook-ceph-rgw-{{ $.Values.s3.crdName }}; do sleep 1; done" ]
      - name: config
        image: rook/ceph:v1.0.0
        command: ["/bin/sh", "-c"]
        args: ["s3cmd --configure --access_key=$(ACCESS-KEY) --secret_key=$(SECRET-KEY) -s --no-ssl --dump-config | tee /config/.s3cfg"]
        volumeMounts:
        - name: config
          mountPath: /config
        env:
        - name: ACCESS-KEY
          valueFrom:
            secretKeyRef:
              name: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}
              key: AccessKey
        - name: SECRET-KEY
          valueFrom:
            secretKeyRef:
              name: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }}
              key: SecretKey
      containers:
      - name: create-bucket
        image: rook/ceph:v1.0.0
        command: 
        - "s3cmd"
        - "mb"
        - "--host=rook-ceph-rgw-{{ $.Values.s3.crdName }}"
        - "--host-bucket= "
        - "s3://{{ $bucket }}"
        ports:
        - name: s3-no-sll
          containerPort: 80
        volumeMounts:
        - name: config
          mountPath: /root
      volumes:
      - name: config
        emptyDir: {}
---
{{- end }}

ഈ ജോലിയിൽ ലിസ്‌റ്റ് ചെയ്‌തിരിക്കുന്ന എല്ലാ പ്രവർത്തനങ്ങളും കുബർനെറ്റസിന്റെ ചട്ടക്കൂടിനുള്ളിൽ നടത്തിയതാണ്. YAML ഫയലുകളിൽ വിവരിച്ചിരിക്കുന്ന ഘടനകൾ ഒരു Git റിപ്പോസിറ്ററിയിൽ സംഭരിക്കുകയും പലതവണ വീണ്ടും ഉപയോഗിക്കുകയും ചെയ്യുന്നു. DevOps എഞ്ചിനീയർമാർക്കും CI/CD പ്രോസസ്സിനും മൊത്തത്തിൽ ഇത് ഒരു വലിയ പ്ലസ് ആയി ഞങ്ങൾ കാണുന്നു.

റൂക്കും റാഡോസുമായി സന്തോഷമുണ്ട്

Ceph + RBD കോമ്പിനേഷൻ ഉപയോഗിക്കുന്നത് പോഡുകളിലേക്ക് വോളിയം മൗണ്ടുചെയ്യുന്നതിന് ചില നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തുന്നു.

പ്രത്യേകിച്ച്, സ്റ്റേറ്റ്ഫുൾ ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിക്കുന്നതിന്, നെയിംസ്പേസിൽ Ceph ആക്സസ് ചെയ്യുന്നതിനുള്ള ഒരു രഹസ്യം ഉണ്ടായിരിക്കണം. നിങ്ങൾക്ക് അവരുടെ നെയിംസ്‌പെയ്‌സിൽ 2-3 പരിതസ്ഥിതികൾ ഉണ്ടെങ്കിൽ കുഴപ്പമില്ല: നിങ്ങൾക്ക് പോയി രഹസ്യം നേരിട്ട് പകർത്താം. എന്നാൽ ഓരോ ഫീച്ചറിനും അതിന്റേതായ നെയിംസ്‌പെയ്‌സുള്ള ഒരു പ്രത്യേക പരിതസ്ഥിതി ഡെവലപ്പർമാർക്കായി സൃഷ്‌ടിച്ചാലോ?

ഞങ്ങൾ ഈ പ്രശ്നം സ്വയം ഉപയോഗിച്ച് പരിഹരിച്ചു ഷെൽ ഓപ്പറേറ്റർ, പുതിയ നെയിംസ്പേസുകളിലേക്ക് രഹസ്യങ്ങൾ സ്വയമേവ പകർത്തി (അത്തരം ഒരു ഹുക്കിന്റെ ഒരു ഉദാഹരണം വിവരിച്ചിരിക്കുന്നു ഈ ലേഖനം).

#! /bin/bash

if [[ $1 == “--config” ]]; then
   cat <<EOF
{"onKubernetesEvent":[
 {"name": "OnNewNamespace",
  "kind": "namespace",
  "event": ["add"]
  }
]}
EOF
else
    NAMESPACE=$(kubectl get namespace -o json | jq '.items | max_by( .metadata.creationTimestamp ) | .metadata.name')
    kubectl -n ${CEPH_SECRET_NAMESPACE} get secret ${CEPH_SECRET_NAME} -o json | jq ".metadata.namespace="${NAMESPACE}"" | kubectl apply -f -
fi

എന്നിരുന്നാലും, റൂക്ക് ഉപയോഗിക്കുമ്പോൾ ഈ പ്രശ്നം നിലവിലില്ല. മൗണ്ടിംഗ് പ്രക്രിയ അതിന്റെ സ്വന്തം ഡ്രൈവറുകൾ ഉപയോഗിച്ചാണ് സംഭവിക്കുന്നത് ഫ്ലെക്സ് വോളിയം അഥവാ സിഎസ്ഐ (ഇപ്പോഴും ബീറ്റ ഘട്ടത്തിലാണ്) അതിനാൽ രഹസ്യങ്ങൾ ആവശ്യമില്ല.

റൂക്ക് സ്വയമേവ നിരവധി പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു, ഇത് പുതിയ പ്രോജക്റ്റുകളിൽ ഇത് ഉപയോഗിക്കാൻ ഞങ്ങളെ പ്രോത്സാഹിപ്പിക്കുന്നു.

റൂക്കിന്റെ ഉപരോധം

റൂക്കിനെയും സെഫിനെയും വിന്യസിച്ചുകൊണ്ട് നമുക്ക് പ്രായോഗിക ഭാഗം പൂർത്തിയാക്കാം, അങ്ങനെ നമുക്ക് നമ്മുടെ സ്വന്തം പരീക്ഷണങ്ങൾ നടത്താം. ഈ അജയ്യമായ ടവറിനെ ആക്രമിക്കുന്നത് എളുപ്പമാക്കുന്നതിന്, ഡെവലപ്പർമാർ ഒരു ഹെൽം പാക്കേജ് തയ്യാറാക്കിയിട്ടുണ്ട്. നമുക്ക് ഇത് ഡൗൺലോഡ് ചെയ്യാം:

$ helm fetch rook-master/rook-ceph --untar --version 1.0.0

ഫയലിൽ rook-ceph/values.yaml നിങ്ങൾക്ക് നിരവധി വ്യത്യസ്ത ക്രമീകരണങ്ങൾ കണ്ടെത്താൻ കഴിയും. ഏജന്റുമാർക്കും തിരയലിനും ടോളറേഷനുകൾ വ്യക്തമാക്കുക എന്നതാണ് ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം. എന്തിനുവേണ്ടിയാണ് കളങ്കങ്ങൾ/സഹിഷ്ണുത സംവിധാനം ഉപയോഗിക്കേണ്ടതെന്ന് ഞങ്ങൾ വിശദമായി വിവരിച്ചു ഈ ലേഖനം.

ചുരുക്കത്തിൽ, ഡാറ്റ സ്റ്റോറേജ് ഡിസ്കുകളുടെ അതേ നോഡുകളിൽ ക്ലയന്റ് ആപ്ലിക്കേഷൻ പോഡുകൾ സ്ഥാപിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല. കാരണം ലളിതമാണ്: ഈ രീതിയിൽ റൂക്ക് ഏജന്റുമാരുടെ പ്രവർത്തനം ആപ്ലിക്കേഷനെ തന്നെ ബാധിക്കില്ല.

അതിനാൽ, ഫയൽ തുറക്കുക rook-ceph/values.yaml നിങ്ങളുടെ പ്രിയപ്പെട്ട എഡിറ്റർ ഉപയോഗിച്ച് അവസാനം ഇനിപ്പറയുന്ന ബ്ലോക്ക് ചേർക്കുക:

discover:
  toleration: NoExecute
  tolerationKey: node-role/storage
agent:
  toleration: NoExecute
  tolerationKey: node-role/storage
  mountSecurityMode: Any

ഡാറ്റ സ്റ്റോറേജിനായി റിസർവ് ചെയ്തിരിക്കുന്ന ഓരോ നോഡിനും, അനുബന്ധ കളങ്കം ചേർക്കുക:

$ kubectl taint node ${NODE_NAME} node-role/storage="":NoExecute

കമാൻഡ് ഉപയോഗിച്ച് ഹെൽം ചാർട്ട് ഇൻസ്റ്റാൾ ചെയ്യുക:

$ helm install --namespace ${ROOK_NAMESPACE} ./rook-ceph

ഇപ്പോൾ നിങ്ങൾ ഒരു ക്ലസ്റ്റർ സൃഷ്ടിച്ച് സ്ഥലം വ്യക്തമാക്കേണ്ടതുണ്ട് OSD:

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  clusterName: "ceph"
  finalizers:
  - cephcluster.ceph.rook.io
  generation: 1
  name: rook-ceph
spec:
  cephVersion:
    image: ceph/ceph:v13
  dashboard:
    enabled: true
  dataDirHostPath: /var/lib/rook/osd
  mon:
    allowMultiplePerNode: false
    count: 3
  network:
    hostNetwork: true
  rbdMirroring:
    workers: 1
  placement:
    all:
      tolerations:
      - key: node-role/storage
        operator: Exists
  storage:
    useAllNodes: false
    useAllDevices: false
    config:
      osdsPerDevice: "1"
      storeType: filestore
    resources:
      limits:
        memory: "1024Mi"
      requests:
        memory: "1024Mi"
    nodes:
    - name: host-1
      directories:
      - path: "/mnt/osd"
    - name: host-2
      directories:
      - path: "/mnt/osd"
    - name: host-3
      directories:
      - path: "/mnt/osd"

Ceph നില പരിശോധിക്കുന്നു - കാണാൻ പ്രതീക്ഷിക്കുന്നു HEALTH_OK:

$ kubectl -n ${ROOK_NAMESPACE} exec $(kubectl -n ${ROOK_NAMESPACE} get pod -l app=rook-ceph-operator -o name -o jsonpath='{.items[0].metadata.name}') -- ceph -s

അതേ സമയം, ക്ലയന്റ് ആപ്ലിക്കേഷനുള്ള പോഡുകൾ Ceph-നായി റിസർവ് ചെയ്തിരിക്കുന്ന നോഡുകളിൽ അവസാനിക്കുന്നില്ലെന്ന് നമുക്ക് പരിശോധിക്കാം:

$ kubectl -n ${APPLICATION_NAMESPACE} get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName

കൂടാതെ, അധിക ഘടകങ്ങൾ ആവശ്യാനുസരണം ക്രമീകരിക്കാൻ കഴിയും. അവരെക്കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ അതിൽ സൂചിപ്പിച്ചിരിക്കുന്നു പ്രമാണീകരണം. അഡ്മിനിസ്ട്രേഷനായി, ഡാഷ്ബോർഡും ടൂൾബോക്സും ഇൻസ്റ്റാൾ ചെയ്യാൻ ഞങ്ങൾ ശക്തമായി ശുപാർശ ചെയ്യുന്നു.

റൂക്കും കൊളുത്തുകളും: എല്ലാത്തിനും റൂക്ക് മതിയോ?

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, റൂക്കിന്റെ വികസനം സജീവമാണ്. എന്നാൽ സെഫിന്റെ മാനുവൽ കോൺഫിഗറേഷൻ പൂർണ്ണമായും ഉപേക്ഷിക്കാൻ ഞങ്ങളെ അനുവദിക്കാത്ത പ്രശ്നങ്ങൾ ഇപ്പോഴും ഉണ്ട്:

• റൂക്ക് ഡ്രൈവർ ഇല്ല ഒന്നും കഴിയില്ല മൗണ്ടഡ് ബ്ലോക്കുകളുടെ ഉപയോഗത്തെക്കുറിച്ചുള്ള മെട്രിക്‌സ് കയറ്റുമതി ചെയ്യുക, ഇത് ഞങ്ങൾക്ക് നിരീക്ഷണം നഷ്ടപ്പെടുത്തുന്നു.
• ഫ്ലെക്സ് വോളിയവും സി.എസ്.ഐ എങ്ങനെയെന്ന് അറിയില്ല വോള്യങ്ങളുടെ വലുപ്പം മാറ്റുക (ഒരേ RBD ന് വിപരീതമായി), അതിനാൽ റൂക്കിന് ഉപയോഗപ്രദമായ (ചിലപ്പോൾ വിമർശനാത്മകമായി ആവശ്യമാണ്!) ഉപകരണം നഷ്ടപ്പെട്ടു.
• റൂക്ക് ഇപ്പോഴും സാധാരണ സെഫിനെപ്പോലെ വഴക്കമുള്ളവനല്ല. SSD-യിൽ സംഭരിക്കുന്ന CephFS മെറ്റാഡാറ്റയ്‌ക്കായി പൂൾ കോൺഫിഗർ ചെയ്യാനും ഡാറ്റ തന്നെ HDD-യിൽ സംഭരിക്കാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ ക്രഷ് മാപ്പുകളിൽ ഉപകരണങ്ങളുടെ പ്രത്യേക ഗ്രൂപ്പുകൾ സ്വമേധയാ രജിസ്റ്റർ ചെയ്യേണ്ടതുണ്ട്.
• Rook-ceph-operator സ്ഥിരതയുള്ളതായി കണക്കാക്കപ്പെടുന്നുണ്ടെങ്കിലും, Ceph പതിപ്പ് 13-ൽ നിന്ന് 14-ലേക്ക് അപ്ഗ്രേഡ് ചെയ്യുമ്പോൾ നിലവിൽ ചില പ്രശ്നങ്ങളുണ്ട്.

കണ്ടെത്തലുകൾ

"ഇപ്പോൾ റൂക്ക് പണയക്കാരാൽ പുറം ലോകത്തിൽ നിന്ന് അടച്ചിരിക്കുന്നു, പക്ഷേ ഒരു ദിവസം അവൾ ഗെയിമിൽ നിർണായക പങ്ക് വഹിക്കുമെന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു!" (ഈ ലേഖനത്തിനായി പ്രത്യേകമായി കണ്ടുപിടിച്ച ഉദ്ധരണി)

റൂക്ക് പ്രോജക്റ്റ് നിസ്സംശയമായും ഞങ്ങളുടെ ഹൃദയം കീഴടക്കി - [അതിന്റെ എല്ലാ ഗുണദോഷങ്ങളോടും കൂടി] ഇത് തീർച്ചയായും നിങ്ങളുടെ ശ്രദ്ധ അർഹിക്കുന്നു എന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു.

ഞങ്ങളുടെ ഭാവി പദ്ധതികൾ റൂക്ക്-സെഫിനെ ഒരു മൊഡ്യൂളാക്കി മാറ്റുന്നു addon-operator, ഇത് ഞങ്ങളുടെ നിരവധി കുബർനെറ്റസ് ക്ലസ്റ്ററുകളിൽ അതിന്റെ ഉപയോഗം കൂടുതൽ ലളിതവും കൂടുതൽ സൗകര്യപ്രദവുമാക്കും.

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «റൂക്ക് - കുബർനെറ്റസിനുള്ള "സ്വയം സേവന" ഡാറ്റ വെയർഹൗസ്";
• «Ceph അടിസ്ഥാനമാക്കി കുബെർനെറ്റസിലെ പ്രൊവിഷനിംഗ് ഉപയോഗിച്ച് സ്ഥിരമായ സംഭരണം സൃഷ്ടിക്കുന്നു";
• «ഡാറ്റാബേസുകളും കുബർനെറ്റുകളും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• «ഷെൽ-ഓപ്പറേറ്റർ അവതരിപ്പിക്കുന്നു: കുബർനെറ്റസിനായി ഓപ്പറേറ്റർമാരെ സൃഷ്ടിക്കുന്നത് ഇപ്പോൾ എളുപ്പമായി";
• «കുബെർനെറ്റസിനായുള്ള ഓപ്പറേറ്റർമാർ: സ്റ്റേറ്റ്ഫുൾ ആപ്ലിക്കേഷനുകൾ എങ്ങനെ പ്രവർത്തിപ്പിക്കാം".

അവലംബം: www.habr.com