التخزين ووحدات التخزين

يشرح هذا الدليل كيفية قيام المشغّل بتوفير التخزين الدائم لـ ClickHouseCluster: وحدة تخزين البيانات الأساسية، وإرفاق أقراص إضافية ضمن بنية متعددة الأقراص (JBOD)، وتوسعة السعة، والقواعد التي تحدد ما يمكنك وما لا يمكنك تغييره بعد إنشاء العنقود. للاطلاع على المرجع المفصل حسب الحقول، راجع تهيئة → Storage configuration ومرجع واجهة برمجة التطبيقات.

وحدة تخزين البيانات الأساسية

spec.dataVolumeClaimSpec هو PersistentVolumeClaimSpec قياسي في Kubernetes. ويحوّله المشغّل إلى volumeClaimTemplate ضمن StatefulSet، بحيث تُنشئ وحدة تحكم StatefulSet عنصر PersistentVolumeClaim واحدًا لكل نسخة متماثلة وتحتفظ به، ثم تربطه بمسار بيانات ClickHouse /var/lib/clickhouse.

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: my-cluster
spec:
  dataVolumeClaimSpec:
    storageClassName: fast-ssd   # optional; depends on the installed CSI driver
    resources:
      requests:
        storage: 100Gi

عند عدم تحديد accessModes، يضبطه المشغّل تلقائيًا على ReadWriteOnce.
يتم الاحتفاظ بـ PVC الخاص بكل نسخة متماثلة عند حذف الـ عنقود، لذا تبقى البيانات بعد حذف المورد المخصص وإعادة إنشائه. وبالنسبة إلى البيانات الموجودة ضمن سياسة مشفّرة، يتطلّب ذلك أيضًا الحفاظ على مفتاح التشفير — راجع الملاحظة في ذلك القسم.
يوجد الحقل نفسه أيضًا في KeeperCluster ويعمل بالطريقة نفسها.

التشغيل بدون وحدة تخزين بيانات دائمة

يكون dataVolumeClaimSpec اختياريًا. إذا حذفته ولم تقم بربط وحدة التخزين الخاصة بك في مسار البيانات، فسيكتب ClickHouse إلى نظام الملفات المؤقت للحاوية، وسيُرجع admission webhook تحذيرًا يفيد بأن البيانات قد تُفقد إذا أُعيد تشغيل العنقود. هذا مخصّص فقط للعناقيد المؤقتة أو الاختبارية. لتوفير وحدة التخزين الخاصة بك بدلًا من dataVolumeClaimSpec — على سبيل المثال emptyDir أو وحدة تخزين مُجهَّزة مسبقًا — عرّفها عبر spec.podTemplate.volumes ثم اربطها في /var/lib/clickhouse باستخدام spec.containerTemplate.volumeMounts.

يُعد dataVolumeClaimSpec ووحدة التخزين المخصّصة في مسار البيانات خيارين متنافيين. إذا تم تعيين dataVolumeClaimSpec، فسيتم رفض ربط وحدة تخزين مخصّصة في /var/lib/clickhouse. ولا يمكن استخدام أسماء وحدات التخزين المحجوزة clickhouse-storage-volume, clickhouse-server-tls-volume, و clickhouse-server-custom-ca-volume في podTemplate.volumes.

توسيع مساحة التخزين

لتوسيع وحدة تخزين، زِد قيمة resources.requests.storage وطبّق التغيير. سيعمل المشغّل على تحديث وحدات PVC الحالية في مكانها.

spec:
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 200Gi   # was 100Gi

لا ينجح التوسيع إلا إذا كانت قيمة allowVolumeExpansion: true مفعّلة في StorageClass الأساسية. لا يدعم Kubernetes تصغير PVC، لذا يجب أن يكون الحجم الجديد أكبر من الحجم الحالي أو مساويًا له.

تخزين متعدد الأقراص (JBOD)

يقوم spec.additionalVolumeClaimTemplates بإرفاق أقراص إضافية بكل نسخة متماثلة من ClickHouse إلى جانب dataVolumeClaimSpec الأساسية. وكل entry عبارة عن قالب PVC مسمّى — يتكوّن من metadata.name وspec الخاصة بـ PVC — وتتم مواءمته تمامًا مثل قرص البيانات الأساسي، بحيث تُنشئ وحدة تحكم StatefulSet وتُبقي PVC واحدة لكل نسخة متماثلة باسم <name>-<statefulset>-0.

spec:
  dataVolumeClaimSpec:
    storageClassName: fast-ssd
    resources:
      requests:
        storage: 100Gi
  additionalVolumeClaimTemplates:
    - metadata:
        name: disk1
      spec:
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi
    - metadata:
        name: disk2
      spec:
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi

يقوم المُشغِّل بربط كل وحدة تخزين إضافية عند /var/lib/clickhouse/disks/<name> ويُنشئ لك storage_configuration الخاصة بـ ClickHouse — لذلك لا تكتبها يدويًا. كما يسجّل كل قرص إضافي ويضيفه إلى سياسة التخزين المضمّنة default. يشترك قرص البيانات الأساسي (default) وكل قرص إضافي في وحدة تخزين واحدة ضمن سياسة default، لذلك يوزّع ClickHouse data parts الجديدة عليها جميعًا بأسلوب round-robin. وتساوي السعة القابلة للاستخدام مجموع كل أقراص، وكل table لا يحدّد storage_policy خاصته — بما في ذلك جداول system.* — يستخدم هذه المجموعة الموحّدة.

يحتفظ مسار الربط باسم القالب كما هو حرفيًا، لكن معرّف القرص داخل storage_configuration يستبدل الشرطات - بشرطات سفلية _. لذلك يُربط قالب باسم cold-disk عند /var/lib/clickhouse/disks/cold-disk ويظهر باسم cold_disk في configuration المُنشأة.

سياسات التخزين المخصّصة

أنت لست بحاجة إلى extraConfig لتخطيط JBOD أعلاه — إذ يُنشئ المُشغِّل سياسة default تلقائيًا. لا تستخدم spec.settings.extraConfig إلا عندما تريد سياسات تخزين تتجاوز الإعداد الافتراضي المُنشأ، مثل سياسة متدرجة للتخزين الساخن/البارد مع move_factor وprefer_not_to_merge، أو قرصًا مدعومًا بـ S3. وأي تهيئة تضيفها هناك تُدمج فوق storage_configuration المُنشأ. راجع وثائق التخزين في ClickHouse للاطلاع على حقول السياسة.

تشفير البيانات المخزَّنة

يؤدي تعيين spec.settings.encryption إلى تفعيل تشفير بيانات الجدول وهي مخزَّنة. ويُنشئ المشغِّل مفتاح AES بطول 16 بايت — يُخزَّن في كائن Secret الخاص بالعنقود المُدار، أو يُوفَّر عبر externalSecret — بالإضافة إلى سياسة تخزين مخصّصة تُغلّف كل قرص بيانات باستخدام نوع القرص encrypted في ClickHouse.

spec:
  settings:
    encryption: {}   # enables the feature; the policy defaults to "encrypted"

يُفعَّل التشفير اختياريًا لكل جدول؛ وتبقى سياسة التخزين الافتراضية غير مشفّرة. حدِّد السياسة المشفّرة عند إنشاء جدول:

CREATE TABLE secret_data (id UInt64) ENGINE = MergeTree ORDER BY id
SETTINGS storage_policy = 'encrypted';

عيّن encryption.policyName لاستخدام اسم سياسة مختلف.

يؤدي هذا إلى تشفير أجزاء بيانات MergeTree المكتوبة عبر السياسة المشفرة باستخدام AES-128-CTR. ولا يشمل ذلك البيانات الوصفية لخادم ClickHouse ولا السجلات الموجودة في جذر البيانات — استخدم تشفيرًا على مستوى القرص مثل LUKS أو برنامج تشغيل CSI لهذه الحالات. يؤدي تمكين التشفير على عنقود قيد التشغيل إلى إعادة تشغيل متدرجة لمرة واحدة لحقن المفتاح؛ وقد تُبلغ النسخ المتماثلة مؤقتًا عن خطأ في إعادة تحميل الإعدادات حتى تكتمل عملية إعادة التشغيل.يُخزَّن المفتاح في Secret الخاص بالعنقود الذي يديره المشغّل، وهو تابع للمورد المخصص ويُحذف معه. تصبح الأجزاء المشفرة غير قابلة للقراءة من دون المفتاح: إذا كان يجب أن تبقى البيانات المشفرة بعد حذف الـ CR (مع الاحتفاظ بـ PVCs)، فوفّر المفتاح عبر externalSecret أو خذ نسخة احتياطية من المُدخل disk-encryption-key قبل الحذف. لا تحذف Secret المُدار — إذ سيُنشئ المشغّل مفتاحًا جديدًا، وستصبح الأجزاء المشفرة الحالية غير قابلة للقراءة.

ما الذي لا يمكنك تغييره بعد الإنشاء

يصبح تخطيط التخزين ثابتًا إلى حدٍّ كبير بمجرد إنشاء عنقود. تُرفض في مرحلة admission التحديثات التي قد تترك PersistentVolumeClaims بدون ارتباط أو تعيد ربطها:

وجود dataVolumeClaimSpec غير قابل للتغيير — لا يمكنك إضافة وحدة تخزين البيانات إلى عنقود أُنشئ من دونه، ولا إزالته من عنقود أُنشئ معه.
تكون مجموعة additionalVolumeClaimTemplates ثابتة — لا يمكنك إضافة عناصر أو إزالتها أو إعادة تسميتها بعد الإنشاء.
يُسمح بتوسيع resources.requests.storage في عنصر موجود (رهناً بدعم StorageClass، راجع توسيع التخزين).
لا يمكن تعطيل التشفير بعد تفعيله، ولا يمكن إعادة تسمية encryption.policyName — إذ ستصبح الجداول التي تستخدم سياسة التشفير بالفعل غير قابلة للوصول.

مرجع التحقق

الشرط	النتيجة
عدم وجود `dataVolumeClaimSpec` وعدم وجود وحدة تخزين مخصّصة عند `/var/lib/clickhouse`	تحذير — احتمال فقدان البيانات عند إعادة التشغيل
ربط وحدة تخزين مخصّصة عند `/var/lib/clickhouse` مع تعيين `dataVolumeClaimSpec`	مرفوض
تعيين `additionalVolumeClaimTemplates` مع غياب `dataVolumeClaimSpec`	مرفوض
قرص إضافي باسم `default`	مرفوض — الاسم محجوز لقرص ClickHouse الافتراضي
اسم قرص إضافي ينتهي بـ `-encrypted`	مرفوض — يتعارض مع أسماء الأقراص المشفّرة المُولَّدة
قرص إضافي باسم `clickhouse-storage-volume`	مرفوض — يتعارض مع اسم وحدة تخزين البيانات الأساسية
تكرار اسم قرص إضافي	مرفوض
اسم لا يطابق `^[a-z]([-a-z0-9]*[a-z0-9])?$` أو يزيد عن 63 حرفًا	مرفوض بواسطة مخطط CRD
إضافة `dataVolumeClaimSpec` أو إزالته بعد الإنشاء	مرفوض
إضافة `additionalVolumeClaimTemplates` أو إزالتها أو إعادة تسميتها بعد الإنشاء	مرفوض
اسم وحدة تخزين محجوز في `podTemplate.volumes`	مرفوض
تعيين `encryption.policyName` إلى `default`	مرفوض بواسطة مخطط CRD — يجب ألا تحلّ السياسة المشفّرة محلّ السياسة الافتراضية
تعطيل `encryption` أو إعادة تسمية سياسته بعد الإنشاء	مرفوض بواسطة مخطط CRD

التهيئة — المرجع الكامل للحقول، بما في ذلك extraConfig.
توسيع نطاق العناقيد — كيفية إضافة النسخ المتماثلة والشظايا وإزالتها.

التثبيت

الأدلة

المرجع

التخزين ووحدات التخزين

وحدة تخزين البيانات الأساسية

التشغيل بدون وحدة تخزين بيانات دائمة

توسيع مساحة التخزين

تخزين متعدد الأقراص (JBOD)

سياسات التخزين المخصّصة

تشفير البيانات المخزَّنة

ما الذي لا يمكنك تغييره بعد الإنشاء

مرجع التحقق

​وحدة تخزين البيانات الأساسية

​التشغيل بدون وحدة تخزين بيانات دائمة

​توسيع مساحة التخزين

​تخزين متعدد الأقراص (JBOD)

​سياسات التخزين المخصّصة

​تشفير البيانات المخزَّنة

​ما الذي لا يمكنك تغييره بعد الإنشاء

​مرجع التحقق

​أدلة ذات صلة

وحدة تخزين البيانات الأساسية

التشغيل بدون وحدة تخزين بيانات دائمة

توسيع مساحة التخزين

تخزين متعدد الأقراص (JBOD)

سياسات التخزين المخصّصة

تشفير البيانات المخزَّنة

ما الذي لا يمكنك تغييره بعد الإنشاء

مرجع التحقق

أدلة ذات صلة