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

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

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

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

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

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

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

لتحقيق أقصى درجات عزل الشبكة والأمان، يمكن لعمليات النشر بنموذج BYOC استخدام AWS PrivateLink أو GCP Private Service Connect. تتيح هذه الخيارات لتطبيقاتك الاتصال بخدمات ClickHouse Cloud عبر اتصال خاص، من دون الحاجة إلى VPC peering أو تعريض نقاط النهاية للإنترنت العام. للحصول على تعليمات إعداد خطوة بخطوة، راجع دليل إعداد الشبكات الخاصة. بشكل افتراضي، تكون نقطة نهاية خادم API لـ Kubernetes الخاصة بعنقود BYOC لديك متاحة عبر الإنترنت العام، لكن الوصول إليها يكون مقيّدًا عبر تصفية عناوين IP بحيث يُسمح فقط بعناوين IP الخاصة ببوابة ClickHouse NAT Gateway. ولمزيد من الأمان، يمكنك تقييد خادم API لـ Kubernetes بحيث لا يمكن الوصول إليه إلا عبر اتصالات الشبكة الخاصة. يتوفر خياران للاتصال الخاص: عند تمكين نقطة نهاية خاصة لواجهة برمجة التطبيقات، تتصل خدمات الإدارة في ClickHouse بخادم Kubernetes API عبر شبكة Tailscale عديمة الثقة نفسها المستخدمة لأغراض استكشاف الأخطاء وإصلاحها. راجع Tailscale Private Network للاطلاع على تفاصيل آلية عمل هذا الاتصال. بالنسبة إلى عمليات النشر على AWS، يمكن بدلًا من ذلك الوصول إلى خادم API الخاص بـ Kubernetes بشكل خاص عبر 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 وخادم API الخاص بـ Kubernetes لديك بالكامل داخل private network الخاصة بـ AWS.
• يتم إنشاء مشاركة RAM من حسابك وتكون محصورة في cluster واحد من نوع BYOC؛ ويؤدي حذفها إلى إلغاء مسار الوصول الخاص فورًا.
• ولأن هذا الوصول لا يعتمد على agent يعمل داخل Kubernetes cluster لديك، يحتفظ ClickHouse Support بإمكانية الوصول لأغراض Troubleshooting حتى إذا أصبحت المكونات داخل الـ cluster غير متاحة.

تواصل مع ClickHouse Support لطلب تهيئة نقطة نهاية واجهة برمجة التطبيقات خاصة. مجموعات عُقد 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 الإدارة المستمرة للموارد والتحجيم لعملية النشر الخاصة بك.