ClickHouseCluster: وحدة تخزين البيانات الأساسية، وإرفاق أقراص إضافية ضمن
بنية متعددة الأقراص (JBOD)، وتوسعة السعة، والقواعد التي تحدد ما يمكنك
وما لا يمكنك تغييره بعد إنشاء العنقود.
للاطلاع على المرجع المفصل حسب الحقول، راجع
تهيئة → Storage configuration
ومرجع واجهة برمجة التطبيقات.
spec.dataVolumeClaimSpec هو PersistentVolumeClaimSpec قياسي في Kubernetes.
ويحوّله المشغّل إلى volumeClaimTemplate ضمن StatefulSet، بحيث تُنشئ وحدة تحكم
StatefulSet عنصر PersistentVolumeClaim واحدًا لكل نسخة متماثلة وتحتفظ به، ثم تربطه
بمسار بيانات ClickHouse /var/lib/clickhouse.
- عند عدم تحديد
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 الحالية في مكانها.
لا ينجح التوسيع إلا إذا كانت قيمة
allowVolumeExpansion: true مفعّلة في StorageClass الأساسية. لا يدعم Kubernetes تصغير PVC، لذا
يجب أن يكون الحجم الجديد أكبر من الحجم الحالي أو مساويًا له.تخزين متعدد الأقراص (JBOD)
spec.additionalVolumeClaimTemplates بإرفاق أقراص إضافية بكل نسخة متماثلة من ClickHouse
إلى جانب dataVolumeClaimSpec الأساسية. وكل entry عبارة عن قالب PVC
مسمّى — يتكوّن من metadata.name وspec الخاصة بـ PVC — وتتم مواءمته تمامًا مثل
قرص البيانات الأساسي، بحيث تُنشئ وحدة تحكم StatefulSet وتُبقي PVC واحدة لكل
نسخة متماثلة باسم <name>-<statefulset>-0.
/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
للاطلاع على حقول السياسة.
ما الذي لا يمكنك تغييره بعد الإنشاء
- وجود
dataVolumeClaimSpecغير قابل للتغيير — لا يمكنك إضافة data وحدة تخزين إلى عنقود أُنشئ من دونه، ولا إزالته من عنقود أُنشئ معه. - تكون مجموعة
additionalVolumeClaimTemplatesثابتة — لا يمكنك إضافة عناصر أو إزالتها أو إعادة تسميتها بعد الإنشاء. - يُسمح بتوسيع
resources.requests.storageفي عنصر موجود (رهناً بدعم StorageClass، راجع توسيع التخزين).
مرجع التحقق
- التهيئة — المرجع الكامل للحقول، بما في ذلك
extraConfig. - توسيع نطاق العناقيد — كيفية إضافة النسخ المتماثلة والشظايا وإزالتها.