البنية المعمارية

يوضح المخطط أدناه كيفية ترابط مؤسسات ClickHouse Cloud والحسابات السحابية والبنية التحتية لـ BYOC.

• مؤسسة ClickHouse Cloud: الكيان الأعلى في ClickHouse Cloud، وهو المسؤول عن إدارة المستخدمين والفوترة وخدمات ClickHouse غير التابعة لـ BYOC. ويمكن للمستخدمين داخل المؤسسة الوصول إلى كلٍّ من خدمات Cloud القياسية وخدمات BYOC.
• مؤسسة ClickHouse BYOC: مؤسسة منفصلة مخصّصة لإدارة عمليات نشر BYOC. وهي تشارك المستخدمين مع مؤسسة Cloud، لكنها ترتبط بحساب سحابي واحد أو أكثر تُنشر فيه البنية التحتية لـ BYOC.
• الحساب السحابي / المشروع / الاشتراك: حساب AWS المملوك للعميل أو مشروع GCP أو اشتراك Azure الذي تُوفَّر فيه البنية التحتية لـ BYOC. ويمكن لكل حساب/مشروع/اشتراك استضافة عمليات نشر BYOC في منطقة واحدة أو أكثر. ويُوصى بتخصيص حساب/مشروع/اشتراك مستقل لكل عملية نشر BYOC لضمان العزل.
• البنية التحتية لـ BYOC: مجموعة الموارد السحابية المنشورة داخل منطقة محددة من حساب سحابي، بما في ذلك VPC/VNet، وعنقود Kubernetes ‏(EKS/GKE/AKS)، وحاويات تخزين الكائنات، وأدوار IAM/حسابات الخدمة/كيانات الخدمة الأساسية، والخدمات الداعمة. ويمكن أن يضم الحساب السحابي الواحد عدة بُنى تحتية لـ BYOC عبر مناطق مختلفة.
• خدمة ClickHouse: عنقود ClickHouse مستقل يعمل ضمن البنية التحتية لـ BYOC. ويمكن تشغيل عدة خدمات ضمن البنية التحتية لـ BYOC نفسها.

• ClickHouse VPC: الـ VPC المملوك لـ ClickHouse Cloud.
• Customer BYOC VPC: الـ VPC المملوك للحساب السحابي للعميل، والذي توفّره وتديره ClickHouse Cloud ويكون مخصّصًا لعملية نشر BYOC على ClickHouse Cloud.
• Customer VPC: شبكات VPC الأخرى المملوكة للحساب السحابي للعميل والمستخدمة للتطبيقات التي تحتاج إلى الاتصال بـ Customer BYOC VPC.

​

البنية المعمارية التقنية

يفصل BYOC بين مستوى التحكم في ClickHouse، الذي يعمل داخل ClickHouse VPC، وطبقة البيانات، التي تعمل بالكامل داخل حسابك السحابي. تستضيف ClickHouse VPC كلاً من ClickHouse Cloud Console، والمصادقة، وإدارة المستخدمين، وواجهات برمجة التطبيقات، والفوترة، ومكوّنات إدارة البنية التحتية مثل متحكّم BYOC، وأدوات التنبيه والاستجابة للحوادث. تتولى هذه الخدمات تنسيق عملية النشر لديك ومراقبتها، لكنها لا تخزّن بياناتك. داخل Customer BYOC VPC، يوفّر ClickHouse عنقود Kubernetes (على سبيل المثال، Amazon EKS) لتشغيل طبقة بيانات ClickHouse. وكما هو موضح في المخطط، يشمل ذلك عنقود ClickHouse نفسه، وClickHouse Operator، والخدمات الداعمة مثل Ingress، وDNS، وإدارة الشهادات، ومُصدّرات الحالة، وأدوات جمع المقاييس. كما تعمل حزمة مراقبة مخصصة (Prometheus وGrafana وAlertManager وThanos) داخل VPC لديك، بحيث تصدر المقاييس والتنبيهات من بيئتك وتبقى بيانات المراقبة نفسها داخل حسابك. وتُرسَل مجموعة محدودة من بيانات القياس عن بُعد التشغيلية إلى ClickHouse Cloud — مقاييس الاستخدام لأغراض الفوترة، وأحداث حالة الخدمة والنسخ الاحتياطي، وتنبيهات السلامة — ولا يُصدَّر أي شيء غير ذلك؛ راجع حدود الشبكة للاطلاع على القائمة الكاملة. وبمعزل عن هذا التصدير، يمكن للوحات معلومات ClickHouse، ولمهندسيها عند التصعيد المعتمد، الاستعلام عن الحزمة وسجلاتك في موضعها عبر Tailscale، دون الاحتفاظ بأي شيء على جانب ClickHouse — راجع وصول ClickHouse إلى البيانات.

الموارد السحابية الرئيسية التي سينشرها ClickHouse Cloud في حسابك هي:

• VPC: سحابة خاصة افتراضية مخصصة لعملية نشر ClickHouse لديك. ويمكن أن تُدار إما بواسطة ClickHouse أو من جانبك أنت، العميل، وعادةً ما تكون مقترنة بنظيراتها من VPC الخاصة بتطبيقاتك.
• أدوار IAM والسياسات: الأدوار والأذونات اللازمة لـ Kubernetes، وخدمات ClickHouse، وحزمة المراقبة. ويمكن أن يوفّرها ClickHouse أو يقدّمها العميل.
• حاويات التخزين: تُستخدم لتخزين أجزاء البيانات، والنسخ الاحتياطية، و(اختياريًا) أرشيفات المقاييس والسجلات طويلة الأمد.
• عنقود Kubernetes: يمكن أن يكون Amazon EKS أو Google GKE أو Azure AKS بحسب مزود الخدمة السحابية لديك. ويستضيف خوادم ClickHouse والخدمات الداعمة الموضحة في مخطط البنية المعمارية.

بشكل افتراضي، يوفّر ClickHouse Cloud VPC جديدة ومخصصة، ويُنشئ أدوار IAM اللازمة لضمان التشغيل الآمن لخدمات Kubernetes. وبالنسبة إلى المؤسسات التي لديها احتياجات متقدمة في الشبكات أو الأمان، يتوفر أيضًا خيار إدارة VPC وأدوار IAM بشكل مستقل. يتيح هذا النهج قدرًا أكبر من تخصيص تهيئة الشبكة وتحكمًا أدق في الأذونات. ومع ذلك، فإن اختيار الإدارة الذاتية لهذه الموارد سيزيد من مسؤولياتك التشغيلية. تبقى بيانات ClickHouse والنسخ الاحتياطية والسجلات وبيانات المراقبة الخاصة بك داخل حسابك السحابي؛ والبيانات الوحيدة التي تُصدَّر إلى خارجه هي بيانات القياس عن بُعد المحدودة الخاصة بالاستخدام والحالة الصحية والمذكورة في حدود الشبكة. تُخزَّن أجزاء البيانات والنسخ الاحتياطية في التخزين الكائني لديك (على سبيل المثال، Amazon S3)، بينما تُخزَّن السجلات على وحدات التخزين المتصلة بعُقد ClickHouse الخاصة بك. في تحديث مستقبلي، ستُكتَب السجلات إلى LogHouse، وهي خدمة سجلات مبنية على ClickHouse وتعمل أيضًا داخل BYOC VPC الخاص بك. ويمكن تخزين المقاييس محليًا أو، للاحتفاظ بها على المدى الطويل، في حاوية مخصصة داخل حسابك الخاص — إذ يقع التخزين الكائني خارج الـ VPC/VNet ويُتاح الوصول إليه عبر مسار واجهة برمجة تطبيقات التخزين لدى المزوّد. ولا يُستخدَم اتصال مستوى التحكم بين ClickHouse VPC وBYOC VPC الخاص بك إلا لعمليات الإدارة، ولا يُستخدَم مطلقًا لحركة الاستعلامات. وافتراضيًا، تصل خدمات إدارة ClickHouse إلى واجهة برمجة تطبيقات Kubernetes الخاصة بالعنقود لديك عبر نقطة النهاية العامة الخاصة به، وهي لا تُترك مفتوحة أبدًا: إذ يُقيَّد الوصول إليها عبر قائمة سماح لعناوين IP تقتصر على نطاقات الخروج الخاصة بـ ClickHouse على AWS، ويُصرَّح به عبر Google Cloud IAM على GCP، وعبر Microsoft Entra ID مع Azure RBAC على Azure. ويمكن بدلًا من ذلك تفعيل اتصال خاص لكل عملية نشر على حدة — عبر AWS VPC Lattice، أو نقطة نهاية مستوى التحكم المستندة إلى DNS في GKE على GCP، أو Azure Private Link — كما هو موضح في المخطط. وتتولى Tailscale نقل وصول مهندسي ClickHouse لاستكشاف الأخطاء وإصلاحها، إلى جانب المقاييس ولوحات المعلومات، على جميع المنصات السحابية، وتبقى قائمة حتى عندما يكون مسار واجهة برمجة تطبيقات Kubernetes خاصًا. يتواصل ClickHouse VPC مع VPC الخاص بـ BYOC عبر HTTPS (المنفذ 443) لتنفيذ عمليات إدارة الخدمة، بما في ذلك تغييرات الإعدادات، وفحوصات الحالة، وأوامر النشر. ولا تنقل هذه الحركة سوى بيانات مستوى التحكم اللازمة للتنسيق. وتتدفق بيانات القياس عن بُعد والتنبيهات الحرجة من VPC الخاص بـ BYOC إلى ClickHouse VPC لتمكين مراقبة استخدام الموارد والحالة. يتطلب نموذج النشر BYOC مكوّنين أساسيين لضمان موثوقية العمليات وسهولة الصيانة والأمان:

​

أذونات IAM عبر الحسابات

تحتاج ClickHouse Cloud إلى أذونات IAM عبر الحسابات لتجهيز الموارد داخل حسابك السحابي وإدارتها. ويُمكّن ذلك ClickHouse من:

• تجهيز البنية التحتية: إنشاء شبكات VPC والشبكات الفرعية ومجموعات الأمان ومكونات الشبكات الأخرى وتهيئتها
• إدارة عناقيد Kubernetes: نشر عناقيد EKS/GKE/AKS ومجموعات العقد ومكونات المجموعة وصيانتها
• إنشاء موارد التخزين: تجهيز حاويات S3 أو تخزين الكائنات المكافئ للبيانات والنسخ الاحتياطية
• إدارة أدوار IAM: إنشاء أدوار IAM وتهيئتها لحسابات خدمة Kubernetes والخدمات المساندة
• تشغيل الخدمات المساندة: نشر حِزم المراقبة ووحدات تحكم الدخول ومكونات البنية التحتية الأخرى وإدارتها

تُمنَح هذه الأذونات من خلال دور IAM عبر الحسابات (AWS) أو حساب خدمة (GCP) أو كيان خدمة متعدد المستأجرين (Azure) تنشئه أثناء عملية الإعداد الأولية. ويتبع هذا الدور مبدأ الحد الأدنى من الامتيازات، بحيث تقتصر الأذونات على ما يلزم فقط لعمليات BYOC. للحصول على معلومات تفصيلية حول الأذونات المحددة المطلوبة، راجع مرجع امتيازات BYOC. يوفّر Tailscale شبكة خاصة آمنة وفق نموذج انعدام الثقة بين ClickHouse Cloud وبيئة نشر BYOC الخاصة بك. وتمرّ عبر هذه الشبكة عمليات وصول مهندسي ClickHouse لاستكشاف الأخطاء وإصلاحها، إضافةً إلى المقاييس ولوحات المعلومات التي تستخدمها ClickHouse لمراقبة بيئة النشر لديك، كما تمرّ عبرها حركة مرور واجهة برمجة تطبيقات Kubernetes عند تفعيل نقطة نهاية خاصة لواجهة برمجة التطبيقات. ويتيح هذا الاتصال ما يلي:

• المراقبة المستمرة: يمكن لمهندسي ClickHouse الوصول إلى حزمة المراقبة Prometheus المنشورة في BYOC VPC لديك لمتابعة سلامة الخدمة وأدائها
• الصيانة الاستباقية: يمكن للمهندسين تنفيذ أعمال الصيانة الدورية وعمليات الترقية واستكشاف الأخطاء وإصلاحها
• الدعم في حالات الطوارئ: في حال حدوث مشكلات في الخدمة، يمكن للمهندسين الوصول سريعًا إلى بيئتك لتشخيص المشكلات وحلّها
• إدارة البنية التحتية: عند تفعيل نقطة نهاية خاصة لواجهة برمجة تطبيقات Kubernetes، تصل خدمات الإدارة إلى واجهة برمجة تطبيقات Kubernetes عبر هذا الاتصال بدلًا من نقطة النهاية العامة الخاصة بها

يُنشئ وكلاء Tailscale في العنقود لديك اتصالات صادرة فقط، فلا حاجة إلى أي قاعدة واردة في مجموعة الأمان أو جدار الحماية أو مجموعة أمان الشبكة من أجل Tailscale نفسه، مما يقلّل من تعرضك للمخاطر. ويكون كل وصول:

• معتمدًا وخاضعًا للتدقيق: يجب على المهندسين طلب الوصول عبر نظام موافقة داخلي
• محدودًا زمنيًا: تنتهي صلاحية الوصول تلقائيًا بعد فترة محددة
• مقيّدًا: لا يمكن للمهندسين الوصول إلا إلى جداول النظام ومكوّنات البنية التحتية، وليس إلى بيانات العملاء مطلقًا
• مشفّرًا: جميع الاتصالات مشفّرة من طرف إلى طرف

تقتصر خاصية الاتصال الصادر فقط هذه على Tailscale نفسه، ولا تشمل جميع مسارات الإدارة. إذ يظل خادم API الخاص بـ Kubernetes في العنقود لديك يقبل الاتصالات الواردة من خدمات الإدارة في ClickHouse على المنفذ TCP 443، سواء عبر نقطة النهاية العامة أو عبر اتصال خاص؛ راجع قائمة الاتصالات الواردة للاطلاع على القائمة الكاملة للمستمعين. للحصول على معلومات تفصيلية حول كيفية عمل Tailscale في BYOC وضوابط الأمان، راجع وثائق أمان الشبكة.

​

لماذا تُعدّ هذه المتطلبات مهمة

يُمكّن هذان المكوّنان معًا ClickHouse Cloud من:

• الحفاظ على الموثوقية: مراقبة بيئتك وصيانتها استباقيًا لتجنّب المشكلات
• ضمان الأمان: استخدام وصول وفق مبدأ أقل الامتيازات مع قابلية تدقيق كاملة
• تبسيط العمليات: أتمتة إدارة البنية التحتية مع الحفاظ على تحكّمك
• تقديم الدعم: الاستجابة السريعة للمشكلات ومعالجتها عند حدوثها

تظل جميع بيانات العملاء داخل حسابك السحابي، ولا يُجرى الوصول إليها أو نقلها مطلقًا عبر قنوات الإدارة هذه. توصيات واعتبارات إضافية:

• تأكد من أن نطاقات CIDR الشبكية الخاصة بـ BYOC VPC لا تتداخل مع أي شبكات VPC حالية تخطط لإعداد VPC peering معها.
• ضع علامات واضحة على مواردك لتسهيل الإدارة والدعم.
• خطّط لحجم مناسب للشبكات الفرعية وتوزيعها عبر مناطق التوفّر لضمان التوافر العالي.
• راجع دليل الأمان لفهم المسؤولية المشتركة وأفضل الممارسات عندما يعمل ClickHouse Cloud داخل بيئتك.
• راجع دليل onboarding الكامل للحصول على إرشادات خطوة بخطوة بشأن الإعداد الأولي للحساب، وتهيئة VPC، واتصال الشبكة (على سبيل المثال، VPC peering)، وتفويض IAM role.

إذا كانت لديك متطلبات أو قيود خاصة، فتواصل مع ClickHouse Support للحصول على إرشادات بشأن تهيئات الشبكة المتقدمة أو سياسات IAM المخصّصة.