تهيئة البنية التحتية

توضح هذه الصفحة خيارات تهيئة البنية التحتية المختلفة المتاحة لنشر BYOC لديك. وتتيح لك هذه التهيئات تخصيص موارد الشبكة والأمان والحوسبة بما يلائم متطلباتك المحددة.

​

موازنات التحميل

تستخدم عمليات نشر BYOC موازنات تحميل الشبكة (NLBs) لإدارة الزيارات وتوجيهها إلى خدمات ClickHouse لديك. يمكنك الاختيار بين نقاط نهاية موازن التحميل العامة والخاصة وفقًا لنموذج الشبكات المعتمد لديك. موازن التحميل العام:

• يوفّر وصولًا عامًا (مكشوفًا للإنترنت) إلى خدمات ClickHouse لديك.
• يكون عادةً مُمكّنًا افتراضيًا عند استخدام VPC مخصص بإدارة ClickHouse.
• يكون معطّلًا افتراضيًا عند استخدام VPC بإدارة العميل لتعزيز الأمان.

موازن التحميل الخاص:

• يوفّر وصولًا خاصًا (داخليًا)، ولا يمكن الوصول إليه إلا من داخل الشبكات المتصلة لديك.
• يكون عادةً مُمكّنًا افتراضيًا عند استخدام VPC بإدارة العميل.
• يكون معطّلًا افتراضيًا عند استخدام VPC مخصص بإدارة ClickHouse.

يمكنك تمكين موازن التحميل الخاص لبنية BYOC التحتية لديك مباشرةً في ClickHouse Cloud console. ولإجراء تعديلات أخرى على نقاط النهاية (مثل إزالة موازن التحميل العام)، تواصل مع ClickHouse Cloud Support.

​

مجموعة الأمان لموازن التحميل الخاص على AWS

إذا اخترت استخدام موازن تحميل خاص لنشر BYOC، فيجب التأكد من تطبيق قواعد مجموعة الأمان المناسبة للسماح بالوصول من شبكاتك الخاصة المستهدفة (مثل شبكات VPC المقترنة). وبشكل افتراضي، لا تسمح مجموعة الأمان إلا بحركة المرور داخل الـ VPC. لإعداد مجموعة الأمان لموازن التحميل الخاص بك: تواصل مع ClickHouse Support لطلب إجراء تغييرات على قواعد مجموعة الأمان الواردة بما يسمح بحركة المرور من شبكات المصدر المحددة لديك:

• VPC Peering: اطلب قواعد تسمح بحركة المرور من نطاقات CIDR الخاصة بشبكات VPC المقترنة لديك.
• PrivateLink: لا يلزم إجراء أي تغييرات على مجموعة الأمان، لأن حركة المرور لا تخضع لمجموعة أمان موازن التحميل.
• إعدادات الشبكة الأخرى: حدِّد السيناريو الخاص بك لكي يتمكن فريق الدعم من المساعدة بالشكل المناسب.

​

PrivateLink أو Private Service Connect أو Private Link

لتحقيق أقصى درجات عزل الشبكة والأمان، يمكن لعمليات النشر بنموذج BYOC استخدام AWS PrivateLink أو GCP Private Service Connect أو Azure Private Link. تتيح هذه الخيارات لتطبيقاتك الاتصال بخدمات ClickHouse Cloud عبر اتصال خاص، من دون الحاجة إلى VPC/VNet peering أو تعريض نقاط النهاية للإنترنت العام. للحصول على تعليمات إعداد خطوة بخطوة، راجع دليل إعداد الشبكات الخاصة.

​

اتصال خاص بواجهة Kubernetes API

بشكل افتراضي، تكون نقطة نهاية خادم Kubernetes API الخاصة بعنقود BYOC لديك متاحة عبر الإنترنت العام. في AWS، يكون الوصول مقيّدًا عبر تصفية عناوين IP بحيث يُسمح فقط بعناوين IP الخاصة ببوابة ClickHouse NAT Gateway؛ أما في GCP وAzure فيُضبط الوصول عبر IAM الخاص بالسحابة بدلًا من ذلك (انظر تعريض خادم Kubernetes API). ولمزيد من الأمان، يمكنك تقييد خادم Kubernetes API بحيث لا يمكن الوصول إليه إلا عبر اتصالات الشبكة الخاصة. تختلف خيارات الاتصال الخاص المتاحة باختلاف مزوّد الخدمة السحابية لديك:

​

Tailscale (default)

عند تمكين نقطة نهاية خاصة لواجهة برمجة التطبيقات، تتصل خدمات الإدارة في ClickHouse بخادم Kubernetes API عبر شبكة Tailscale عديمة الثقة نفسها المستخدمة لأغراض استكشاف الأخطاء وإصلاحها. راجع Tailscale Private Network للاطلاع على تفاصيل آلية عمل هذا الاتصال.

​

AWS VPC Lattice

بالنسبة إلى عمليات النشر على AWS، يمكن بدلًا من ذلك الوصول إلى خادم Kubernetes API بشكل خاص عبر AWS VPC Lattice، من دون أي مكونات تابعة لجهة خارجية:

• يوفّر ClickHouse Cloud تلقائيًا VPC Lattice Resource Gateway وResource Configuration تستهدف endpoint الخاص بـ خادم API لـ EKS داخل VPC الخاص بـ BYOC لديك، ويشارك Resource Configuration مع حساب إدارة ClickHouse Cloud عبر AWS Resource Access Manager ‏(RAM).
• تبقى حركة البيانات بين management services في ClickHouse وخادم Kubernetes API لديك بالكامل داخل private network الخاصة بـ AWS.
• يتم إنشاء مشاركة RAM من حسابك وتكون محصورة في عنقود واحد من نوع BYOC؛ ويؤدي حذفها إلى إلغاء مسار الوصول الخاص فورًا.
• ولأن هذا الوصول لا يعتمد على وكيل يعمل داخل عنقود Kubernetes لديك، يحتفظ ClickHouse Support بإمكانية الوصول لأغراض استكشاف الأخطاء وإصلاحها حتى إذا أصبحت المكونات داخل العنقود غير متاحة.

​

نقطة النهاية الخاصة لطبقة التحكم في GCP

في عمليات النشر على GCP، يمكن تعطيل نقطة نهاية طبقة التحكم المستندة إلى عناوين IP في عنقود GKE، فلا يعود الوصول إليها ممكنًا من الإنترنت العام. وعندئذٍ تصل خدمات إدارة ClickHouse إلى طبقة التحكم عبر نقطة النهاية المستندة إلى DNS ‏(*.gke.goog)، ويُصرَّح بهذا الوصول من خلال صلاحية IAM ‏container.clusters.connect الممنوحة لحساب الخدمة الذي تنتحل ClickHouse هويته في مشروعك، لا من خلال قائمة سماح قائمة على عناوين IP المصدر.

• يخضع الوصول بالكامل لنظام IAM السحابي في مشروعك، ولذا فإن سحب تلك الصلاحية يُغلق مسار الوصول هذا.
• ينتهي الطلب عند الواجهة الأمامية لـ Google لا داخل شبكة VPC الخاصة بك، لذا قيِّمه باعتباره مسار وصول إلى طبقة التحكم لديك، لا باعتباره رابطًا شبكيًا خاصًا.
• يظل مهندسو ClickHouse يعتمدون على Tailscale للوصول لأغراض استكشاف الأخطاء وإصلاحها.

​

Azure Private Link

في عمليات النشر على Azure، يمكن الوصول إلى خادم API الخاص بـ AKS بشكل خاص عبر Azure Private Link:

• يُنشأ العنقود بوصفه عنقودًا خاصًا مع تفعيل API Server VNet Integration، ويُعطَّل اسم النطاق المؤهل بالكامل (FQDN) العام الخاص به.
• تُجهّز ClickHouse Cloud خدمة Private Link Service في اشتراكك أمام موازن التحميل الداخلي لخادم API، إلى جانب نقطة نهاية خاصة مقابلة في الشبكة الافتراضية (VNet) المخصصة لإدارة ClickHouse Cloud. ولا تُمنح الموافقة التلقائية على الاتصال إلا لاشتراك الإدارة التابع لـ ClickHouse Cloud.
• تظل حركة البيانات بين خدمات إدارة ClickHouse وخادم API الخاص بك ضمن الشبكة الأساسية لـ Azure.
• يظل وصول مهندسي ClickHouse لاستكشاف الأخطاء وإصلاحها معتمدًا على Tailscale.

تواصل مع ClickHouse Support لطلب تهيئة نقطة نهاية API خاصة.

​

مجموعات العُقد

مجموعات عُقد Kubernetes هي مجموعات من مثيلات الحوسبة التي توفّر الموارد اللازمة لتشغيل خدمات ClickHouse الخاصة بك في نشر BYOC. وتدير ClickHouse Cloud مجموعات العُقد هذه، فتتولى تلقائيًا إعدادها وتوسيع نطاقها.

​

الإعداد الافتراضي

تُوفَّر مجموعات BYOC بنوعين أساسيين من مجموعات العُقد:

• مجموعة عُقد النظام تستضيف أعباء النظام الأساسية، مثل ClickHouse Operator وIstio (لشبكة الخدمات) ومكوّنات المراقبة (Prometheus وGrafana وAlertManager) وcluster autoscaler وغيرها من الخدمات الأساسية. وتستخدم هذه العُقد عادةً أنواع المثيلات القياسية من x86.
• مجموعات عُقد أعباء العمل تُخصَّص لأعباء بيانات ClickHouse، بما في ذلك الخوادم وخدمات Keeper. وبشكل افتراضي، تعمل عُقد أعباء العمل على مثيلات تستند إلى ARM، ما يوفّر توازنًا فعّالًا بين الأداء والتكلفة. ومع ذلك، يمكن أيضًا تهيئتها بملفات تعريف بديلة للمعالج/الذاكرة أو تحويلها إلى معمارية x86 عند الطلب.

​

تخصيص مجموعات العُقد

هل تحتاج إلى موارد أو معمارية متخصصة؟ تتوفر التخصيصات التالية — تواصل مع ClickHouse Support لمناقشتها وتنفيذها:

• اختيار نوع المثيل اختر أنواع مثيلات محددة لتلبية متطلبات مثل الأداء، والامتثال، وارتفاع الذاكرة/CPU، أو للاستفادة من الموارد المحجوزة.
• نِسَب CPU/الذاكرة اضبط ملف الحوسبة التعريفي لمجموعات عُقد أعباء العمل حسب الحاجة.
• المعمارية بدّل مجموعات عُقد أعباء العمل من ARM إلى x86 إذا لزم الأمر.

ملاحظة: مثيلات Spot (القابلة للاستباق) غير مدعومة؛ تعمل جميع مجموعات عُقد BYOC على مثيلات عند الطلب افتراضيًا.

​

التحجيم التلقائي

تتوسع مجموعات عُقد العنقود تلقائيًا عبر cluster autoscaler، استنادًا إلى ما يلي:

• طلبات موارد الـ Pod وحدودها
• السعة الإجمالية للعنقود ومستوى استخدامه
• متطلبات تحجيم خدمة ClickHouse

لا يلزم أي تدخل يدوي. يتولى ClickHouse Cloud الإدارة المستمرة للموارد والتحجيم لعملية النشر الخاصة بك.