الأسئلة الشائعة
من يمكنه تغيير خدماتي، ومتى؟
في الوضع المُدار، لا تُغيّر ClickHouse Cloud سوى الخدمات التي طلبت منها إدارتها. ويمكن أيضًا لأي شخص لديه وصول إلى مضيف الـ منفّذ أو كبسولة الخاصة به التحكم بها عبر أوامرclicklink clctl instances المحلية؛ انظر دورة حياة الخدمة. وترسل ClickHouse Cloud أوامر دورة الحياة عبر القناة الصادرة للـ منفّذ:
- الإنشاء، انطلاقًا من التعريف الذي قدّمته
- التوسيع، إلى عدد ثابت من النسخ المتماثلة تحدده ClickHouse Cloud (مُقيَّد بإعداد في ClickHouse Cloud، وهو 20 في التهيئة الافتراضية)
- الإيقاف والتشغيل وإعادة التشغيل
- النسخ الاحتياطي وحذف النسخ الاحتياطي
- الحذف
clicklink clctl executor prepare وclicklink clctl instances create، لأنك وحدك من يمكنه إنشاء الحاويات ودور IAM. كذلك تنتظرك تحديثات مكوّنات المنصة في العنقود الخاص بك. يُجهّز الـ منفّذ كل حزمة مقترحة؛ ويعتمدها أمر clicklink clctl platform approve ويُصدر رمزًا صالحًا لساعتين. انظر تحديثات المنصة.
وكل ما يفعله الـ منفّذ يجري عبر واجهة برمجة تطبيقات Kubernetes. وتُقيّد سياسة admission عمليات الكتابة الخاصة به بمساحات الأسماء التي تحمل prefix الخدمة (ns- افتراضيًا). كما تسمح بثلاث عمليات كتابة في مساحة الأسماء الخاصة بالـ منفّذ: تجديد الرمز، وConfigMap الخاص بـ سجل الخدمات، وعلى Kubernetes الشهادة المُجدَّدة للعميل في الـ Secret المسمى clicklink-mtls. أما عمليات القراءة لعائلات الموارد نفسها فتشمل العنقود بالكامل. وتُنفَّذ تحديثات المنصة المعتمدة بهوية منفصلة هي pcm-platform مُقيَّدة بمساحات أسماء المنصة. ولا تُمَس أبدًا العناقيد التي تديرها بنفسك: فـ scraper ومستكشف الأخطاء ومصلحها للقراءة فقط. وتجد النطاقات الدقيقة في صفحة نموذج الامتيازات.
ما هي البيانات التي تخرج من بيئتي؟
هناك ثلاثة مسارات ترسل البيانات إلى الخارج، وجميعها عبر اتصالات صادرة يفتحها الموصّل بنفسه: مسار السحب، والمنفّذ، وجلسات الدعم التي تقوم بتمكينها. يرسل scraper نتائج من مجموعة ثابتة من جداول النظام هي افتراضيًا:metric_log، وasynchronous_metric_log، وtables، وwarnings، وserver_settings. كما يرسل heartbeats للصحة والحالة، وحالة الـ خدمة والنسخ الاحتياطية، ومقاييس الموصّل نفسه. ولا تشمل مجموعة السحب الافتراضية system.query_log. فنص SQL الخام، بما يحتويه من قيم حرفية أو بيانات شخصية، لا يخرج أبدًا عبر مسار السحب ما لم تُضِف ذلك الجدول بنفسك. وأثناء الجلسة، تتضمن قائمة الجداول المسموح بها افتراضيًا system.processes التي تعرض نص الاستعلامات الجارية؛ فأزِلها من قائمة السماح إذا كان يجب أن يبقى ذلك مخفيًا.
يرسل المنفّذ نتيجة كل أمر ينفّذه، وحالة كل خدمة مُدارة وعدد نسخه المتماثلة. وتُبلّغ heartbeat عمّا إذا كانت قناة أوامره متصلة. كما تحمل إصدارات مكونات المنصة، وبصمة آخر حزمة طبّقها، ونتيجة آخر تحديث للمنصة. وفي حالة التثبيت على جهاز افتراضي، تُبلّغ heartbeat أيضًا عمّا إذا كانت حزمة وصول Kubernetes الخاصة به ok أو expiring أو expired أو غير موجودة. وعند إنشاء خدمة، يرسل clicklink clctl instances create معرّف بيئتك، والسحابة والمنطقة، واسم الـ خدمة، وأسماء الحاويات الخاصة به و دور IAM ARN. كما يرسل تجزئتين لكلمة مرور المستخدم default؛ أما كلمة المرور نفسها فلا تخرج أبدًا.
وأثناء جلسة الدعم النشطة، يُعيد مستكشف الأخطاء ومصلحها مخرجات الأوامر أيضًا. وتقتصر هذه المخرجات على جداول ClickHouse المسموح بها وعروض Kubernetes للقراءة فقط، بما في ذلك سجلات الـ كبسولة. وتمر عبر التنقيح (أنماط مدمجة لعناوين IP وبيانات الاعتماد والرموز والمفاتيح، إضافة إلى أنماطك الخاصة) قبل إرسالها. أما بيانات جداولك والنسخ الاحتياطية وسجل الاستعلامات (system.query_log، system.text_log) فتبقى داخل بيئتك. وهناك ثلاثة أمور تخرج فعلًا:
- الصفوف الواردة من جداول سجل المقاييس المسموح بها (
system.metric_log،system.asynchronous_metric_log) تُرسل مع كل عملية سحب - نص الاستعلامات الجارية يكون مرئيًا في الجلسة عبر
system.processesما لم تُزِله من قائمة السماح - سجلات الـ كبسولة التي تُقرأ أثناء جلسة دعم Kubernetes تخرج بعد التنقيح
كيف أمنع ClickHouse من تغيير عناقيدي؟
شغّله بدون الوضع المُدار. عند التثبيت، مرّر--no-managed إلى clicklink clctl init، أو أجب بالنفي عند السؤال. لا يُنشر سوى scraper ومستكشف الأخطاء ومصلحها، وبذلك لا يستطيع ClickHouse إنشاء الخدمات أو تغييرها أو حذفها. ومع ذلك يستمر الموصّل في تجهيز مستخدمي ClickHouse للقراءة فقط وحسابات ServiceAccount؛ راجع نموذج الامتيازات.
أمّا في التثبيتات القائمة، فأوقف المنفّذ وأزل امتياز مسؤول العنقود الممنوح له. لإيقافه، اضبط executor.enabled: false في قيم Helm الخاصة بك ثم شغّل helm upgrade، أو شغّل systemctl disable --now clicklink-executor على جهاز افتراضي. بعد ذلك أزل الامتياز. ويحذف الأمر الأخير حساب ServiceAccount نفسه؛ ومساحة الأسماء الخاصة به هي clicklink-system في تثبيتات الأجهزة الافتراضية، ومساحة أسماء الموصّل في تثبيتات Kubernetes:
ماذا يحدث إذا كان الموصّل غير متصل؟
لا تتأثر خدمات ClickHouse لديك: فـ الموصّل لا يقع ضمن أي data path، وتواصل الخدمة المُدارة عملها دون منفّذ. أما الأثر فهو فقدان الرؤية والتحكم؛ إذ يتوقف ClickHouse Cloud عن استقبال بيانات القياس عن بُعد، وتصبح جلسات الدعم غير متاحة حتى يعود الموصّل. وفي الوضع المُدار، يعرض ClickHouse Cloud بيئتك على أنها غير متصلة إذا لم تصل أي نبضة قلب خلال 5 دقائق، ثم يعرضها جاهزة مجددًا فور وصول النبضة التالية. وتتصرف أوامر دورة الحياة بطريقتين ما دام لا يوجد منفّذ متصل. فأي أمر إنشاء أو حذف أو مزامنة منصة سبق أن قبله ClickHouse Cloud يُحتفظ به وتُعاد محاولته: تُعاد محاولة الإنشاء لمدة تصل إلى 30 دقيقة من آخر تقرير تقدّم، والحذف لمدة تصل إلى ساعتين، ومزامنة المنصة لما يصل إلى 10 محاولات، وبعد ذلك يُبلَّغ عن فشل الأمر. والحدّان الزمنيان هما مفتاحا التهيئةexecutor.create_retry_horizon وexecutor.delete_retry_horizon. أما كل أمر آخر (scale، stop، start، restart، backup، حذف backup)، وأي أمر إنشاء أو حذف يُرسَل بينما لا يوجد منفّذ متصل، فيُرفض عند الإرسال ولا يُوضع في قائمة انتظار. وتُرسَل أي نتيجة لم يتمكن المنفّذ من الإبلاغ عنها عند اتصاله التالي. راجع عندما يكون الموصّل غير متصل.
وعلى جهاز افتراضي، يخزّن scraper البيانات المسحوبة مؤقتًا في /var/lib/clicklink/buffer كلما تعذّر الوصول إلى نقطة نهاية الموصّل (لمدة تصل إلى 168 ساعة أو 1024 ميغابايت افتراضيًا)، ثم يسلّم ما خزّنه عند إعادة الاتصال، فلا يؤدي انقطاع نقطة النهاية إلى فقدان أي بيانات قياس عن بُعد. ويُعاد تشغيل أي برنامج خفي متعطل بواسطة systemd على الجهاز الافتراضي وبواسطة kubelet على Kubernetes. كما يحفظ المنفّذ حالة أوامره على القرص، بحيث تستأنف إعادة التشغيل الأوامر التي كانت قيد التنفيذ.
وللتشخيص، تحقق من نقطة نهاية /livez لكل مكوّن (المؤشر هو حقل status في JSON، وليس رمز HTTP) ونفّذ clicklink clctl preflight (مع sudo على مضيف الجهاز الافتراضي). يفحص Preflight التهيئة والاتصال وإمكانية الوصول إلى ClickHouse والصلاحيات والقرص في مسار واحد. راجع العمليات؛ وإذا ظل الموصّل غير سليم، فتواصل مع دعم ClickHouse.
ما الذي يُحذف عند حذف الخدمة؟
يوقف المُنفِّذ الخدمة، ويزيل موارد Kubernetes الخاصة بها، ويحذف مساحة الأسماء التابعة لها، ثم يُبلغ عن إنهاء الخدمة بمجرد اختفاء مساحة الأسماء. أما كل ما هو خارج Kubernetes فيبقى كما هو: حاوية البيانات، وحاوية النسخ الاحتياطي، ودور IAM الخاص بالخدمة. فالمُنفِّذ لا يمتلك أي بيانات اعتماد لحاويات التخزين الخاصة بك أو لـ IAM، ولذلك لا يمكنه المساس بها. أما الباقي فتزيله بالأمرclicklink clctl executor teardown مع تشغيله ببيانات الاعتماد الخاصة بك. وهو يزيل افتراضيًا دور IAM ويُبقي على البيانات والنسخ الاحتياطية، أما حذفها فيتطلب تمرير خيارات صريحة. راجع حذف خدمة.
أين أجد كلمة مرور المستخدم default؟
يولّدها الأمرclicklink clctl executor prepare على جهازك ويطبعها مرة واحدة فقط. وإذا أرسلت الطلب باستخدام الخيارات الفردية بدلاً من --from-prepare، فإن clicklink clctl instances create يقرأها من --default-user-password-file أو ينشئها ويطبعها. ولا تُرسل إلى ClickHouse Cloud سوى قيم الـ hashes الخاصة بها، ولذلك لا يمكن للـ موصّل ولا لـ ClickHouse عرضها لك مرة أخرى. احرص على حفظها فور ظهورها.
كيف أسحب صلاحية وصول ClickHouse؟
بالترتيب التصاعدي:- إنهاء الوصول التفاعلي. عطّل الجلسة باستخدام:
sudo clicklink clctl troubleshoot session disableعلى مضيف الـجهاز الافتراضي، أو باستخدام الأمر نفسه مع--gateway-urlعبر إعادة توجيه المنفذ في Kubernetes (تجد الأوامر الدقيقة في صفحة جلسات الدعم). عند عدم وجود جلسة نشطة، يرفض مستكشف الأخطاء ومصلحها تنفيذ أي أمر، حتى لو كان الاتصال قائماً. - إيقاف الوضع المُدار. أوقف المنفّذ وألغِ صلاحيته كما هو موضح في كيف أمنع ClickHouse من تغيير عناقيدي؟. تتطلب تحديثات المنصة موافقتك أصلاً، لذا فإن حجبها يوقفها.
- منع الجلسات المستقبلية. أفرغ قائمة السماح الخاصة بالمشغّل (إذ تؤدي قائمة السماح الفارغة إلى إغلاق البوابة) أو عطّل البوابة؛ على الـجهاز الافتراضي، تظل إدارة الجلسات المحلية متاحة للمستخدم root على المضيف. راجع دليل التهيئة.
- قطع اتصال ClickHouse Cloud. احظر حركة الخروج إلى نقطة نهاية الموصل على مستوى الشبكة، أو أفرغ
networkPolicy.allowEgressCIDRsضمن CNI مفروض. إذ يعمل الموصل للاتصالات الصادرة فقط، لذلك لا يملك ClickHouse Cloud مساراً وارداً لاستعادة الاتصال. تستمر عمليات القراءة المحلية من ClickHouse إلى أن توقف أعباء العمل أو تلغي تثبيتها، وهذا هو الإيقاف النهائي. - إلغاء بيانات الاعتماد. احذف مستخدمي ClickHouse
pcm_scraperوpcm_troubleshooter، واحذف أسرار الموصل (Kubernetes) أو الملفات الموجودة ضمن/etc/clicklink(جهاز افتراضي). - إزالة الموصل بالكامل. راجع العمليات.
هل يمكنني تشغيل هذا في بيئة معزولة (air-gapped) أو عبر مرايا خاصة بي؟
نعم. يمكن أن يأتي كل artifact مطلوب وقت التثبيت من داخل حدود شبكتك:- انسخ أرشيف CLI وصورة الحاوية من
releases.clicklink.clickhouse.comومن السجل العام إلى مرآتك، ثم وجّهimage.repositoryإلى مرآتك. - مرّر
--chartمع مرجعoci://أو URL أو أرشيف محلي. القيمة الافتراضية لـ--chart-versionهي إصدار الـ CLI نفسه. - إذا كانت نقطة نهاية الموصّل مُقدَّمة داخل حدود شبكتك خلف private CA، فإن
--api-private-ca(في Kubernetes) أوapi.tls.ca_file(في الجهاز الافتراضي) يُلحق سلسلة CA الخاصة بحزمة التسجيل بجذور النظام. - للتسجيل دون اتصال مباشر، يستهلك
init --handoffحزمة يتم الحصول عليها خارج القناة، بينما يُكمل--no-auto-signمعinit --signed-certتوقيع الشهادة خارج القناة. - في الوضع المُدار، يمكن أن تأتي صور ClickHouse الخاصة بخدماتك ومكوّنات المنصة من سجلك الخاص بعد استيرادها إليه، وتتولى ClickHouse تسجيل ذلك السجل لبيئتك.
- يمكن تسليم حزم المنصة خارج القناة وتمريرها كملف إلى
clicklink clctl platform approve --bundle.
كيف تُدقَّق جلسات الدعم؟
يُضاف كل أمر يُنفَّذ أثناء الجلسة، سواء قُبل أو حُظر، إلى/var/log/clicklink/troubleshoot-audit.log بتنسيق JSON المحدد بأسطر جديدة. ويسجل كل إدخال submitted_by (معرّف المؤسسة على قناة الأوامر)، ونص الأمر، والمثيل الهدف، والنتيجة، وblocked_by للأوامر المرفوضة. أما طلبات البوابة، بما فيها المرفوضة، فتُسجَّل كأسطر clctl.gateway مهيكلة في سجل مستكشف الأخطاء ومصلحها نفسه. وتُنسب إلى البريد الإلكتروني للمشغّل المثبت بالرمز المميز، وليس اسمًا يبلّغه المستخدم بنفسه مطلقًا. وتسجل تغييرات الجلسات المحلية على جهاز افتراضي مستخدم المضيف الذي استدعاها في الحقل enabled_by ضمن /var/lib/clicklink/session.json.
والجلسات محددة المدة (4 ساعات افتراضيًا، و24 ساعة كحد أقصى). ويسجل كل تفعيل من فعّله ووقت انتهائه وسببًا اختياريًا، ويعرض ذلك الأمر clicklink clctl troubleshoot session status.
اقرأ سجل التدقيق باستخدام clicklink clctl troubleshoot audit tail. في Kubernetes، يُعد هذا الأمر القارئ المدعوم (إذ لا تحتوي صورة runtime على shell). ومع الإعداد الافتراضي persistence.enabled: true، يُخزَّن السجل على وحدة التخزين الدائمة الخاصة بمستكشف الأخطاء ومصلحها، بحيث يبقى سجل التدقيق محفوظًا عند إعادة جدولة كبسولة. يؤدي تعطيل التخزين الدائم إلى ربط سجل التدقيق وحالة الجلسة بعمر كبسولة، ويشير chart إلى أن هذا الخيار مناسب للتطوير المحلي فقط. تحتفظ عملية التدوير افتراضيًا بـ 5 ملفات، يصل حجم كل منها إلى 128 MB، لمدة 168 ساعة؛ راجع مرجع التهيئة لضبط ذلك، وجلسات الدعم للاطلاع على نموذج الثقة الكامل.