> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# BYOC FAQ

> الأسئلة الشائعة حول ClickHouse Bring Your Own Cloud ‏(BYOC)

<div id="faq">
  ## الأسئلة الشائعة
</div>

<div id="onboarding-and-provisioning">
  ### الإعداد الأولي وتوفير البنية التحتية
</div>

<Accordion title="كيف نبدأ باستخدام BYOC؟">
  تواصل مع ClickHouse عبر [نموذج الاتصال](https://clickhouse.com/cloud/bring-your-own-cloud)، وسيقوم الفريق بتمكين BYOC لمؤسستك. بعد ذلك، جهّز حسابًا سحابيًا مخصصًا (حساب AWS أو مشروع GCP أو اشتراك Azure) واتبع [دليل الإعداد الأولي القياسي](/ar/products/bring-your-own-cloud/onboarding/standard). نوصي بشدة باستخدام حساب أو مشروع أو اشتراك مخصص حصريًا لـ BYOC.
</Accordion>

<Accordion title="كم يستغرق توفير البنية التحتية، وما الأسباب الشائعة لتعطّله؟">
  توقّع أن تستغرق العملية نحو 45–90 دقيقة من البداية إلى النهاية. ويرجع اتساع هذا النطاق إلى أن معظم الوقت يُستهلك في توفير موفر الخدمة السحابية للموارد (عنقود Kubernetes وموازنات التحميل ومكونات الشبكة)، وهي عملية تختلف مدتها من تشغيل لآخر وتقع خارج سيطرة ClickHouse. وعندما يتعطل التوفير، تكون الأسباب الأكثر شيوعًا مرتبطة بالحساب:

  * تعديل قالب CloudFormation أو وحدة Terraform قبل تطبيقهما — مثلًا بإضافة `PermissionsBoundary` أو بإعادة تسمية دور IAM لتلبية اصطلاح تسمية معين (في AWS، احتفظ بالاسم الافتراضي `ClickHouseManagementRole` ما لم توافق ClickHouse صراحةً على اسم مختلف). طبّق العناصر كما تم توفيرها — إذ تتوفر التخصيصات المدعومة كمعلمات، وأي تغيير آخر يتطلب موافقة ClickHouse مسبقًا.
  * سياسات على مستوى المؤسسة (AWS SCPs أو سياسات مؤسسة GCP مثل `iam.allowedPolicyMemberDomains` أو سياسات Azure التي تقيّد تعيينات الأدوار) تمنع تولّي الأدوار أو ربط IAM.
  * عدم تطابق المعرّف الخارجي في دور الإعداد الأولي (راجع سؤال المعرّف الخارجي أدناه).
  * حدود حصة الحساب (مثل Elastic IPs أو VPCs في AWS).

  تُعاد محاولة التوفير تلقائيًا، وتتعافى العملية ذاتيًا بمجرد حل المشكلة الأساسية. إذا ظلت بنيتك التحتية عالقة لأكثر من بضع ساعات، فاتصل بالدعم.
</Accordion>

<Accordion title="ما القيمة التي ينبغي استخدامها للمعرّف الخارجي في قالب الإعداد الأولي؟">
  ينشئ ClickHouse Cloud console معرّفًا خارجيًا لحساب AWS الخاص بك عند بدء الإعداد الأولي، ويملؤه مسبقًا في رابط CloudFormation (المعلمة `ExternalID`)؛ وإذا كنت تستخدم Terraform، فمرّر القيمة نفسها باعتبارها `external_id`. تشترك جميع البنى التحتية لـ BYOC ضمن حساب AWS نفسه في المعرّف الخارجي نفسه. لا تختر قيمة بنفسك: يجب أن تتطابق مع ما تتوقعه أتمتة ClickHouse، وإلا فلن يمكن تولّي الدور عبر الحسابات وسيفشل التوفير. راجع [المعرّف الخارجي لـ AWS](/ar/products/bring-your-own-cloud/onboarding/standard#aws-external-id) للتفاصيل.
</Accordion>

<Accordion title="لماذا يكون معرّفي الخارجي emptyid؟">
  تستخدم البنى التحتية لـ BYOC التي تم إعدادها قبل إدخال المعرّفات الخارجية القيمة النائبة `emptyid` للتوافق مع الإصدارات السابقة. عند إضافة بنية تحتية جديدة إلى حساب AWS يتضمن نشرًا قديمًا قائمًا، يعيد Console استخدام هذه القيمة النائبة كي تحافظ جميع البنى التحتية في الحساب على تكوين ثقة متسق. إذا كنت ترغب في التبديل إلى معرّف خارجي فريد، فاتصل بـ ClickHouse Support.
</Accordion>

<Accordion title="هل يمكن لـ BYOC استخدام شبكة VPC الحالية؟ وماذا عن شبكات VPC المشتركة؟">
  في AWS وGCP، يمكنك النشر في شبكة VPC الحالية الموجودة في **الحساب أو المشروع نفسه** الذي توجد فيه بنية BYOC التحتية. راجع أدلة التخصيص لـ [AWS](/ar/products/bring-your-own-cloud/onboarding/customization-aws) و[GCP](/ar/products/bring-your-own-cloud/onboarding/customization-gcp). في GCP، تُدعم أيضًا **Shared VPC** من مشروع مضيف منفصل: تقبل [وحدة الإعداد الأولي](https://github.com/ClickHouse/terraform-byoc-onboarding/tree/main/modules/gcp) المشروع المضيف والشبكة الفرعية مباشرةً — راجع قسم "Shared VPC" فيها للتعرف على الإعداد والمتطلبات الأساسية. ستتوفر قريبًا إمكانية إحضار VNet الخاصة بك في Azure.

  في AWS، لا تُدعم الشبكات الفرعية المشتركة من حساب آخر (AWS RAM) — استخدم بدلًا من ذلك حسابًا مخصصًا متصلًا بشبكتك الحالية عبر VPC peering أو PrivateLink. لاحظ أنه عند استخدام VPC يديرها العميل، لا يتم تمكين سوى موازن التحميل الخاص افتراضيًا (راجع [التكوين](/ar/products/bring-your-own-cloud/configuration/configurations)).
</Accordion>

<Accordion title="هل يمكن تثبيت BYOC في عنقود Kubernetes قائم؟">
  لا. يتم إنشاء عنقود Kubernetes ‏(EKS أو GKE أو AKS) وإدارته بالكامل بواسطة ClickHouse. وهذا مطلوب كي تتمكن ClickHouse من تشغيل المنصة بموثوقية والحفاظ عليها محدّثة.
</Accordion>

<Accordion title="هل يمكننا تشغيل أعباء العمل الخاصة بنا في عنقود BYOC أو حساب سحابي؟">
  في حساب سحابي: هذا ممكن، لكن الموارد الموجودة في الموقع نفسه تقع دائمًا، بدرجة ما، ضمن نطاق أذونات ClickHouse — ففي AWS تكون معظم أذونات الكتابة مقيّدة بالعلامات والبادئات (تحمل الموارد التي يوفّرها ClickHouse العلامة `clickhouse-byoc=true`)، لكن مجموعة صغيرة من إجراءات EC2 لا يمكن تقييدها بالعلامات. أما في GCP وAzure، فلدى هويات الإعداد الأولي أذونات على مستوى المشروع أو الاشتراك. أبقِ مواردك بعيدة عن الموارد التي يوفّرها ClickHouse، ويفضّل استخدام حساب أو مشروع أو اشتراك مخصص في كل Cloud — إذ تظل هذه توصيتنا الأساسية.

  في عنقود Kubernetes: هذا ممكن ضمن قيود — استخدم مجموعات العقد الخاصة بك مع التلويثات ووسائل التحمّل، وابقَ خارج مساحات الأسماء التي يديرها ClickHouse، ولا تثبّت وحدات تحكم قبول أو محركات سياسات على مستوى العنقود، إذ قد تعيق تسوية مكونات ClickHouse. اشرح خطتك لفريق الدعم كي نتمكن من التأكد من عدم وجود أي تعارضات.
</Accordion>

<div id="compute">
  ### الحوسبة والتحجيم
</div>

<Accordion title="هل يمكنني إنشاء عدة خدمات ضمن بنية أساسية واحدة لـ BYOC؟">
  نعم. لا يلزم توفير البنية الأساسية، بما في ذلك عنقود Kubernetes، إلا مرة واحدة لكل مجموعة من حساب/مشروع/اشتراك سحابي ومنطقة، وتشترك فيها جميع الخدمات التي تنشئها في تلك المنطقة.
</Accordion>

<Accordion title="ما المناطق التي تدعمونها لـ BYOC؟">
  تتوفر جميع **المناطق العامة** المدرجة في وثائق [المناطق المدعومة](/ar/products/cloud/reference/supported-regions) لعمليات نشر BYOC. يوفّر BYOC الموارد عبر ثلاث مناطق توافر، لذا لا تُدعم المناطق التي تحتوي على أقل من ثلاث مناطق توافر، ولا AWS Local Zones. إذا لم تكن المنطقة التي تحتاج إليها مدرجة، فاتصل بممثل ClickHouse لمناقشة مدى توفرها.
</Accordion>

<Accordion title="هل توجد أعباء إضافية على الموارد؟ وما الموارد اللازمة لتشغيل الخدمات بخلاف مثيلات ClickHouse؟">
  إلى جانب مثيلات ClickHouse نفسها، بما في ذلك خوادم ClickHouse وClickHouse Keeper، نشغّل أيضًا خدمات داعمة مثل `clickhouse-operator` وcluster autoscaler وIstio وحزمة المراقبة.

  استهلاك الموارد لهذه المكونات المشتركة مستقر نسبيًا ولا يزداد خطيًا مع عدد خدمات ClickHouse أو حجمها. كإرشاد تقريبي، يبلغ إجمالي مجموعة عقد النظام المخصصة لهذه أعباء العمل نحو 48 وحدة vCPU و192 غيغابايت من الذاكرة — أي ما يعادل على AWS، مثلًا، نحو ست مثيلات من نوع `2xlarge`. بالإضافة إلى ذلك، يشغّل كل مستودع مجموعة ClickHouse Keeper مخصصة تتألف من ثلاث عقد، وتشترك فيها جميع الخدمات ضمن ذلك المستودع. راجع [نموذج التكلفة](/ar/products/bring-your-own-cloud/reference/cost-model-aws) للتفاصيل.
</Accordion>

<Accordion title="هل يدعم BYOC التحجيم التلقائي؟">
  التحجيم التلقائي الرأسي على مستوى الخدمة مدرج في خارطة الطريق. المتاح حاليًا: التحجيم الرأسي والأفقي اليدوي عبر Console، والتحجيم المجدول لأنماط الحمل المتوقعة، والتعطيل وإعادة التشغيل تلقائيًا لأعباء العمل المتقطعة، والتحجيم التلقائي لمجموعات العقد على مستوى البنية الأساسية — ولن تحتاج إلى إدارة العقد بنفسك مطلقًا. تراقب ClickHouse خدمة ClickHouse Keeper وتُحجّمها.
</Accordion>

<Accordion title="على أي أنواع مثيلات يعمل BYOC؟ وهل يمكننا تغيير عائلة المثيل؟">
  يعمل BYOC على مجموعة منتقاة من مجموعات العقد بدلًا من أنواع المثيلات العشوائية. تعمل مجموعات عقد أعباء العمل، وهي خوادم ClickHouse وKeeper، افتراضيًا على مثيلات محسّنة للذاكرة ومعتمدة على ARM، مثل Graviton على AWS، بينما تستخدم مجموعة عقد النظام عادةً مثيلات x86. يمكن توفير عائلات مثيلات أو نسب CPU إلى الذاكرة أو بُنى مختلفة عند الطلب عبر الدعم؛ ولا تُدعم مثيلات Spot. راجع [configuration](/ar/products/bring-your-own-cloud/configuration/configurations).
</Accordion>

<Accordion title="هل يمكننا تشغيل نسخ متماثلة صغيرة جدًا لخفض التكاليف؟">
  تعمل كل نسخة متماثلة كـ pod واحد على عقدة خاصة بها — إذ يُطابق حجم العقدة حجم النسخة المتماثلة، وتُوفَّر العقد عند الطلب، ولا تُوضَع نسخ متماثلة متعددة على عقدة واحدة مطلقًا. لذلك، تكون النسخ المتماثلة الصغيرة جدًا غير فعّالة: إذ يستهلك الحمل الإضافي حصة أكبر من العتاد، كما يزداد عرض نطاق الشبكة والقرص مع حجم المثيل. أما الأحجام الأصغر مما توفره Console فتتطلب طلبات مخصصة عبر الدعم.
</Accordion>

<Accordion title="هل يمكننا فصل أعباء عمل الاستيعاب والاستعلام؟">
  نعم. يدعم BYOC المستودعات (فصل الحوسبة عن الحوسبة): تشترك خدمات متعددة في البيانات نفسها، لذا يمكنك تخصيص خدمات للاستيعاب وأخرى للاستعلام.
</Accordion>

<div id="network-and-security">
  ### الشبكة والأمان
</div>

<Accordion title="هل يمكننا تقييد الأذونات الممنوحة أثناء التثبيت أو سحبها؟">
  يمكنك تقليص الامتيازات منذ البداية على AWS وGCP: إذ إن مكوّنات الإعداد الأولي قابلة للتهيئة عبر المعلمات، لذا يمكنك حجب أذونات إدارة طوبولوجيا شبكة VPC الخاصة بك عند استخدام VPC خاصة بك (`IncludeVPCWritePermissions` في CloudFormation، و`include_vpc_write_permissions` في وحدات Terraform). على GCP، يقتصر ذلك على إدارة الطوبولوجيا فقط — إذ يحتفظ ClickHouse بإذن الكتابة إلى موارد الشبكة التي يملكها داخل VPC، مثل الشبكة الفرعية NAT لـ Private Service Connect، ومرفق الخدمة، وعناوين الإدخال. على AWS، يمكنك أيضًا — ضمن معاينة خاصة تُفعَّل عبر الدعم — إدارة IAM roles بنفسك (`IncludeIAMWritePermissions=false`، راجع [IAM roles التي يديرها العميل](/ar/products/bring-your-own-cloud/onboarding/customization-aws))، كما تُحمى الأدوار المشتركة بين الحسابات بمعرّف خارجي لمنع هجمات النائب الملتبس. على Azure، تمنح وحدة الإعداد الأولي دورًا ثابتًا على مستوى الاشتراك، من دون معلمات لتحديد النطاق حاليًا. في جميع السحب، لا تُطلب بعض الأذونات إلا لميزات محددة، ويمكن إزالتها إذا كنت لن تستخدم تلك الميزات مطلقًا — تواصل مع الدعم إذا احتجت إلى تقييد الأذونات بما يتجاوز ما تتيحه هذه المكوّنات.

  بعد التوفير، لا تزل الأذونات من هوية الإدارة من جانب واحد: إذ يطابق ClickHouse البنية التحتية باستمرار مع الحالة المطلوبة، وقد تؤدي الأذونات المفقودة إلى تعطل التوفير والترقيات والدعم. لتغيير الأذونات الممنوحة أو إلغاء الإعداد بالكامل، نسّق مع الدعم (راجع سؤال إيقاف الخدمة أدناه).
</Accordion>

<Accordion title="ما الذي يمكن لـ ClickHouse فعله بالضبط في حسابنا السحابي؟ وهل يمكن لفريق الأمان لدينا مراجعة الأذونات؟">
  يوفر [مرجع الامتيازات](/ar/products/bring-your-own-cloud/reference/privilege) نظرة عامة على كل Role وهوية والغرض منهما على AWS وGCP وAzure. بالنسبة إلى هوية الإعداد الأولي (التمهيد)، تحدد المكوّنات المنشورة نطاق السياسات الدقيق — [CloudFormation template](https://s3.us-east-2.amazonaws.com/clickhouse-public-resources.clickhouse.cloud/cf-templates/byoc_v2.yaml) و[وحدات Terraform](https://github.com/ClickHouse/terraform-byoc-onboarding) — ويمكن لفريق الأمان لديك تدقيقها مباشرةً. تُوضَّح الهويات الإضافية التي ينشئها ClickHouse بعد الإعداد الأولي (أدوار وحدة التحكم وحسابات الخدمة والهويات المُدارة) لكل مزود في مرجع الامتيازات، وبما أنها موجودة في حسابك، يمكنك فحص سياساتها الفعلية في وحدة التحكم السحابية لديك ومراجعة إنشائها واستخدامها في CloudTrail أو ما يعادله في GCP/Azure. على AWS، يُحدَّد نطاق معظم أذونات الكتابة لدور الإدارة بواسطة علامات الموارد وبادئات الأسماء مثل `clickhouse-cloud-*`، لذلك لا يمكنه عمومًا تعديل الموارد التي لم ينشئها (إذ لا يمكن تحديد نطاق عدد قليل من إجراءات EC2 بالعلامات)، وليس لديه **أي وصول على مستوى الكائنات إلى حاويات بياناتك** — إذ يقتصر الوصول إلى الكائنات على الهويات داخل cluster والمحددة النطاق لأحمال عمل ClickHouse. على GCP وAzure، تمتلك هويات الإعداد الأولي أذونات على مستوى المشروع أو الاشتراك بدلًا من ذلك — وهو أحد أسباب التوصية بشدة بمشروع أو اشتراك مخصص. أذونات القراءة أوسع نطاقًا لأنها مطلوبة للمطابقة المستمرة.
</Accordion>

<Accordion title="ما مستوى الوصول الذي يتمتع به موظفو ClickHouse إلى بيئتنا وبياناتنا؟">
  افتراضيًا، لا يملكون أي وصول إلى بياناتك. لاستكشاف الأخطاء وإصلاحها، يجب على المهندسين المرور بعملية escalation داخلية تمنح وصولًا فوريًا عند الحاجة؛ ويكون هذا الوصول مقيّدًا زمنيًا، ومعتمدًا على الشهادات، ومحدودًا بجداول `system.*` (من دون جداول بيانات العملاء)، ويُسجَّل ويُدقَّق من قبل فريق الأمان لدينا. يظهر لك أي query ينفذه مهندس ClickHouse في `system.query_log` الخاص بك. ولتشخيص البنية التحتية، يمكن لعملية escalation نفسها، بعد الموافقة، أن تمنح وصولًا مقيّدًا زمنيًا إلى Kubernetes API server وحزمة المراقبة داخل cluster عبر Tailscale. راجع [ClickHouse data access](/ar/products/bring-your-own-cloud/reference/clickhouse-data-access) للاطلاع على نموذج الوصول إلى البيانات، و[أمان الشبكة](/ar/products/bring-your-own-cloud/reference/network-security) للاطلاع على نموذج الاتصال.
</Accordion>

<Accordion title="هل أخذتم في الاعتبار ضوابط أمان مستقبلية لوصول مهندسي ClickHouse إلى البنية التحتية للعملاء لاستكشاف الأخطاء وإصلاحها؟">
  نعم. إن تنفيذ آلية يتحكم بها العميل، تتيح له الموافقة على وصول المهندسين إلى cluster، مدرج في خارطة طريقنا. في الوقت الحالي، يجب على المهندسين المرور بعملية escalation الداخلية لدينا للحصول على وصول فوري إلى cluster. يُسجَّل ذلك ويُدقَّق من قبل فريق الأمان لدينا.
</Accordion>

<Accordion title="ما البيانات التي تغادر حسابنا؟">
  البيانات الوصفية التشغيلية فقط: أحداث حالة الخدمة والنسخ الاحتياطي، ومقاييس الاستخدام لأغراض الفوترة، وإشعارات التنبيهات. تبقى بياناتك ونسخك الاحتياطية وسجلاتك وبيانات Monitoring في حسابك. راجع [أمان الشبكة](/ar/products/bring-your-own-cloud/reference/network-security) للاطلاع على القائمة الكاملة للتدفقات الصادرة.
</Accordion>

<Accordion title="كيف يصل مستوى التحكم في ClickHouse إلى واجهة برمجة تطبيقات Kubernetes في حسابنا؟ هل يلزم استخدام Tailscale؟">
  افتراضيًا، تكون نقطة نهاية واجهة برمجة تطبيقات Kubernetes عامة، لكنها مقيّدة بعناوين IP الخاصة ببوابة NAT لدى ClickHouse. ما دام هذا الإعداد الافتراضي قيد الاستخدام، فلا تحذف إدخالات قائمة السماح الخاصة بـ ClickHouse، إذ يحتاجها مستوى التحكم لإدارة العنقود. يمكن بدلًا من ذلك تحويل نقطة النهاية إلى وصول خاص فقط، بالتنسيق مع فريق ClickHouse: عبر Tailscale (للخروج فقط، ويُستخدم أيضًا للوصول لأغراض استكشاف الأخطاء وإصلاحها) أو، على AWS، عبر VPC Lattice (معاينة خاصة) — راجع [configuration](/ar/products/bring-your-own-cloud/configuration/configurations). لاحظ أن هذا ينطبق على واجهة برمجة تطبيقات Kubernetes فقط: إذ تنطلق استدعاءات واجهة برمجة تطبيقات موفر السحابة (مثل EKS وEC2 على AWS) من شبكة ClickHouse Cloud عبر افتراض دور عبر الحسابات، ولا يمكن مطلقًا توجيهها عبر Tailscale — راجع [واجهات برمجة تطبيقات موفر السحابة مقابل واجهة برمجة تطبيقات Kubernetes](/ar/products/bring-your-own-cloud/reference/network-security#cloud-api-vs-kubernetes-api).
</Accordion>

<Accordion title="كيف تعمل الاتصالات الشبكية بين شبكة BYOC وتخزين الكائنات؟">
  على AWS، تستخدم حركة البيانات بين Customer BYOC VPC الخاص بك وS3 بروتوكول HTTPS (المنفذ 443) عبر واجهة برمجة تطبيقات AWS S3 لبيانات table والنسخ الاحتياطية والسجلات. تمر هذه الحركة عبر نقطة نهاية VPC من نوع بوابة لـ S3، لذا تبقى داخل شبكة AWS ولا تعبر الإنترنت العام ولا تترتب عليها رسوم بوابة NAT. وبالمثل، على GCP، يستخدم الوصول إلى واجهات برمجة تطبيقات Google خدمة Private Google Access. وعلى Azure، تُخزَّن البيانات في حسابات Azure Blob Storage ضمن اشتراكك.
</Accordion>

<Accordion title="البيانات موجودة في حاوية خاصة بنا — هل يمكننا قراءتها أو تعديلها مباشرةً؟">
  لا. تُخزَّن كائنات blob لبيانات table ضمن تخطيط مشترك من دون مسارات مخصصة لكل table، لذلك لا يمكن إسناد objects إلى tables، وأي تعديل مباشر قد يؤدي إلى تلف خدماتك. لا تعدّل محتويات حاوية مباشرةً مطلقًا؛ وإذا اشتبهت في وجود مشكلة، فافتح طلب دعم.
</Accordion>

<Accordion title="ما المنافذ المستخدمة لاتصالات العميل والعنقود؟">
  تنتهي اتصالات client عند موازن التحميل على منافذ TLS: **8443** (واجهة HTTPS) و**9440** (native protocol عبر TLS)؛ كما يوجّه المنفذ 443 إلى واجهة HTTPS. لا تكون MySQL interface (المنفذ 3306) مكشوفة حاليًا في BYOC — وهي مدرجة في خارطة الطريق (راجع [overview](/ar/products/cloud/guides/infrastructure/deployment-options/byoc/overview)).

  داخل الشبكة، تستخدم الاتصالات الداخلية للعنقود native protocol على المنفذ 9000، وHTTP على المنفذ 8123، واتصالات interserver على المنفذ 9009 للنسخ المتماثل وdistributed queries. لا تُكشف هذه المنافذ الداخلية ومنافذ ClickHouse Keeper مطلقًا على أي موازن التحميل.
</Accordion>

<Accordion title="هل نقاط نهاية خدماتنا مكشوفة للإنترنت العام؟ هل يمكننا جعلها خاصة فقط؟">
  مع VPC مُدار من ClickHouse، تحصل كل service افتراضيًا على موازن التحميل عام محمي بقائمة وصول IP؛ ويمكن أيضًا تمكين موازن التحميل خاص، الذي يمكن الوصول إليه من شبكتك والشبكات المقترنة بها، في ClickHouse Cloud console (راجع [Load Balancers](/ar/products/bring-your-own-cloud/configuration/configurations#load-balancers)). مع VPC مُدار من العميل، تنعكس الإعدادات الافتراضية ولا يتم تمكين سوى موازن التحميل خاص. يُفرض ترشيح IP على طبقة ingress proxy، لذا قد تبدو منافذ موازن التحميل مفتوحة في عمليات الفحص، بينما تُرفض الاتصالات من المصادر غير المدرجة. يمكن تعطيل public endpoint بالكامل بمجرد ألا يعتمد عليه أي شيء. يعرض [محدد Connection via](/ar/products/bring-your-own-cloud/configuration/connect#connection-via) في Console نقاط النهاية لكل مسار connection مُمكّن لخدمتك. راجع [connectivity](/ar/products/bring-your-own-cloud/configuration/connect).
</Accordion>

<Accordion title="هل يمكننا استخدام نطاق DNS الخاص بنا أو إحضار شهادات TLS الخاصة بنا؟">
  ليس حاليًا. تُوفَّر نقاط نهاية service ضمن `clickhouse-byoc.com` مع certificates مُدارة بواسطة ClickHouse.
</Accordion>

<Accordion title="كيف نُعد AWS PrivateLink أو GCP Private Service Connect أو Azure Private Link؟">
  اتبع أدلة إعداد الشبكة لـ [AWS](/ar/products/bring-your-own-cloud/onboarding/network-aws) و[GCP](/ar/products/bring-your-own-cloud/onboarding/network-gcp) و[Azure](/ar/products/bring-your-own-cloud/onboarding/network-azure). هناك أمران غالبًا ما يتم إغفالهما: إضافة نقاط النهاية إلى قائمة السماح تكون **لكل خدمة**، لذا يجب تسجيل نقاط النهاية مجددًا لكل خدمة جديدة، كما يجب إعداد تحليل DNS لأسماء نقاط النهاية الخاصة من جانبك إذا كنت تشغّل DNS الخاص بك. بعد الإعداد، استخدم [محدد Connection via](/ar/products/bring-your-own-cloud/configuration/connect#connection-via) في Console لنسخ اسم مضيف نقطة النهاية الخاصة الصحيح.
</Accordion>

<Accordion title="هل يمكننا الاتصال عبر PrivateLink من منطقة AWS مختلفة؟">
  نعم، لكن مفتاح التبديل **Enable private link** في وحدة التحكم لا يشمل سوى المستهلكين ضمن المنطقة نفسها — إذ تعطل AWS الوصول عبر المناطق لخدمات نقاط النهاية افتراضيًا، ولا تديره ClickHouse console. وبما أن خدمة نقطة النهاية موجودة في حساب BYOC الخاص بك، فعليك تفعيل ذلك بنفسك: أضف مناطق المستهلكين إلى قائمة **Supported regions** لخدمة نقطة النهاية في وحدة تحكم AWS، ثم أنشئ نقطة النهاية مع تفعيل خيار الاتصال عبر المناطق من جانب المستهلك. لن تغيّر ClickHouse هذه القيم أو تعيد ضبطها. راجع [دليل إعداد PrivateLink](/ar/products/bring-your-own-cloud/onboarding/network-aws#setup-privatelink) للاطلاع على الخطوات؛ وتُطبق رسوم AWS لنقل البيانات عبر المناطق.
</Accordion>

<Accordion title="هل توجد قائمة بنقاط النهاية التي نحتاج إلى السماح بها في جدار الحماية أو قواعد الخروج لدينا؟">
  لا توجد قائمة موحدة منشورة بنقاط النهاية. تتطلب العنقود اتصالًا فعالًا بالإنترنت للخروج (مباشرةً أو عبر NAT)، بالإضافة إلى وصول خاص إلى واجهات برمجة تطبيقات موفر السحابة — راجع [متطلبات اتصال الشبكة](/ar/products/bring-your-own-cloud/onboarding/customization-aws#ensure-network-connectivity). إذا كانت سياسة الشبكة لديك تتطلب قائمة صريحة، فاتصل بالدعم لمراجعة إعدادك.
</Accordion>

<Accordion title="رصدت أدوات الأمان لدينا حاويات ذات امتيازات أو نقاط تحميل للمضيف في عنقود BYOC — هل هذا متوقع؟">
  تتطلب بعض مكونات المنصة، بصورة مشروعة، امتيازات مرتفعة أو وصولًا إلى نظام ملفات المضيف، مثل برنامج تشغيل EBS CSI ووظائف تهيئة العقد ومُصدّر عقد Prometheus (الذي يقرأ `/proc` و`/sys`). إذا أظهرت أداة الفحص لديك نتائج، فشاركها مع الدعم — وسنؤكد ما إذا كانت كل منها مقصودة بحكم التصميم أو تتطلب إجراءً.
</Accordion>

<Accordion title="هل تدعمون مفاتيح التشفير التي يديرها العميل (CMEK)؟">
  ليس حاليًا لـ BYOC. تُشفّر البيانات أثناء التخزين باستخدام مفاتيح يديرها موفر السحابة. راجع [النظرة العامة](/ar/products/cloud/guides/infrastructure/deployment-options/byoc/overview) للاطلاع على القائمة الحالية للميزات المخطط لها.
</Accordion>

<div id="upgrades-and-maintenance">
  ### الترقيات والصيانة
</div>

<Accordion title="كيف تعمل ترقيات إصدارات ClickHouse؟ وهل يمكنني تحديد وتيرة الصيانة؟">
  تعمل الترقيات بالطريقة نفسها المتبعة في ClickHouse Cloud: تُدرَج الخدمات ضمن قنوات الإصدار (السريعة والمنتظمة والبطيئة) وتلتزم بنوافذ الصيانة المجدولة — تواصل مع الدعم لإعدادها. توقّع جدول تحديث أسبوعي على الأقل. تُنفَّذ الترقيات تدريجيًا، نسخة متماثلة تلو الأخرى (الإنشاء قبل الإزالة)، لذا لا يحدث توقف كامل للخدمة. راجع [العمليات](/ar/products/bring-your-own-cloud/configuration/operations).
</Accordion>

<Accordion title="من المسؤول عن ترقيات Kubernetes، وما التأثير المتوقع؟">
  يتولى ClickHouse ترقيات Kubernetes وينفذها استباقيًا قبل تواريخ انتهاء الدعم لدى المزوّد، وينسّق نافذة الصيانة معك عبر الدعم. تكون ترقيات مستوى التحكم شفافة، أما ترقيات مجموعات العُقد فتتم بعقدة تلو الأخرى وفق نهج الإنشاء قبل الإزالة، لذا قد تلاحظ إعادة تعيين وجيزة للاتصالات عند إعادة تشغيل القرون، ولكن دون فقدان البيانات. راجع [العمليات](/ar/products/bring-your-own-cloud/configuration/operations).
</Accordion>

<div id="backups-and-disaster-recovery">
  ### النسخ الاحتياطية والتعافي من الكوارث
</div>

<Accordion title="أين تُخزَّن النسخ الاحتياطية؟">
  في تخزين الكائنات ضمن حسابك السحابي الخاص — لا تغادر النسخ الاحتياطية بيئتك مطلقًا. يمكن تهيئة جدول النسخ الاحتياطي ومدة الاحتفاظ؛ اتصل بالدعم لتعديلهما.
</Accordion>

<Accordion title="ما الذي تتضمنه النسخة الاحتياطية؟ وهل تُنسخ جداول النظام احتياطيًا؟">
  جميع قواعد البيانات والجداول والكائنات التي أنشأها المستخدم، بالإضافة إلى كيانات الوصول (المستخدمون والأدوار وملفات تعريف الإعدادات وسياسات الصفوف والحصص) والدوال المعرّفة من قبل المستخدم. لا تُضمَّن جداول سجلات النظام، مثل `system.query_log`.
</Accordion>

<Accordion title="لماذا تُفرض عليّ رسوم مقابل النسخ الاحتياطية الأقدم من نافذة الاحتفاظ؟">
  تشكّل النسخ الاحتياطية سلاسل: نسخة احتياطية كاملة تتبعها نسخ تزايدية تعتمد عليها. النسخة الاحتياطية الكاملة الأساسية مطلوبة لاستعادة أي نسخة تزايدية ضمن سلسلتها، لذا يُحتفَظ بها (وتُخزَّن) إلى أن تنتهي مدة الاحتفاظ بجميع النسخ التزايدية التابعة لها.
</Accordion>

<Accordion title="كيف يمكننا مراقبة حالة النسخ الاحتياطية بأنفسنا؟">
  بطريقتين: نقاط نهاية النسخ الاحتياطية في ClickHouse Cloud API، ومقاييس النسخ الاحتياطية (عدادات البدء والإكمال والفشل) التي تعرضها حزمة المراقبة داخل الكتلة — نوصي بإعداد تنبيهات لحالات الفشل في نظام المراقبة الخاص بك. راجع [قابلية الرصد](/ar/products/bring-your-own-cloud/reference/observability-aws).
</Accordion>

<Accordion title="كيف نلبي متطلبات التعافي من الكوارث (RPO/RTO)؟">
  يُنشر BYOC عبر ثلاث مناطق توافر، ولا يُقَرّ بعمليات الكتابة إلا بعد أن يؤكد تخزين الكائنات استلامها. لا يتوفر النسخ المتماثل عبر المناطق حاليًا، لذا يعتمد التعافي من الكوارث على مستوى المنطقة على النسخ الاحتياطية، وتقتصر قيمة RPO القابلة للتحقيق على تكرار النسخ الاحتياطي. يمكن تهيئة تكرار النسخ الاحتياطي ووجهته لتتوافق مع أهدافك، بما في ذلك إجراء نسخ احتياطي إلى حاوية في منطقة أخرى — اتصل بالدعم لإعداد ذلك.
</Accordion>

<div id="observability">
  ### قابلية الرصد
</div>

<Accordion title="كيف ندمج BYOC مع أنظمة المراقبة والتنبيهات الخاصة بنا؟">
  تعمل حزمة المراقبة (Prometheus وGrafana وAlertManager) ضمن حسابك، ويمكنك استخدامها مباشرةً عبر الاتصال الخاص: الاستعلام عنها من خلال واجهة برمجة تطبيقات PromQL، أو ربطها اتحاديًا مع Prometheus الخاص بك، أو سحب المقاييس من نقطة النهاية `/metrics_all` في ClickHouse لكل خدمة. لا يتوفر حاليًا تكامل جاهز مع منصات خارجية مثل Datadog — بل يمكنك التكامل عبر آلية الاستيعاب المتوافقة مع Prometheus. راجع [قابلية الرصد](/ar/products/bring-your-own-cloud/reference/observability-aws) للاطلاع على نقاط النهاية والإعداد.
</Accordion>

<div id="cost">
  ### التكلفة
</div>

<Accordion title="مقابل ماذا ندفع في BYOC؟">
  فاتورتان منفصلتان: تفرض ClickHouse Cloud رسوماً استناداً إلى الذاكرة المخصصة لخدماتك، بينما يُصدر موفّر الخدمة السحابية فاتورةً مباشرةً عن البنية التحتية الأساسية بسعر التكلفة، من دون أي هامش ربح. تغطي صفحات مرجع التكلفة التفصيلية حالياً AWS: راجع [نموذج التكلفة](/ar/products/bring-your-own-cloud/reference/cost-model-aws)، و[خدمات AWS الخاضعة للفوترة](/ar/products/bring-your-own-cloud/reference/billable-aws-services)، و[حدود خدمات AWS](/ar/products/bring-your-own-cloud/reference/aws-service-limits).
</Accordion>

<div id="availability-and-lifecycle">
  ### التوافر ودورة الحياة
</div>

<Accordion title="لدى أي موفري خدمات سحابية يتوفر BYOC؟">
  تتوفر AWS وGCP وAzure بشكل عام للاستخدام الإنتاجي. راجع [النظرة العامة](/ar/products/cloud/guides/infrastructure/deployment-options/byoc/overview) للتعرّف على الميزات والمناطق المدعومة في كل سحابة.
</Accordion>

<Accordion title="كيف نلغي تشغيل بيئة BYOC؟">
  أنه خدماتك وبنية BYOC التحتية من ClickHouse console — لا تبدأ بحذف الموارد أو سحب الأذونات من وحدة تحكم موفر الخدمة السحابية، لأن ذلك يقطع اتصال مستوى التحكم أثناء العملية ويفرض إجراء تنظيف يدوي. بعد اكتمال الإنهاء عبر وحدة التحكم، أزل حزمة الإعداد الأولي (CloudFormation stack أو وحدة Terraform) وأي موارد متبقية. في AWS، تُوسم جميع الموارد التي أنشأها ClickHouse بالوسم `clickhouse-byoc=true`، لذا يمكنك حصرها لاحقًا للتحقق من عدم بقاء أي منها؛ أما في GCP وAzure، فيحدّد المشروع أو الاشتراك المخصص الذي أعددته نطاق ما ينبغي مراجعته.
</Accordion>

<div id="uptime-sla">
  ### اتفاقيات مستوى الخدمة لوقت التشغيل
</div>

<Accordion title="هل يوفّر ClickHouse اتفاقية مستوى خدمة لوقت التشغيل لـ BYOC؟">
  لا، نظرًا لأن طبقة البيانات مستضافة في البيئة السحابية الخاصة بالعميل، فإن توفّر الخدمة يعتمد على موارد لا تقع ضمن سيطرة ClickHouse. لذلك، لا يوفّر ClickHouse اتفاقية مستوى خدمة رسمية لوقت التشغيل لعمليات نشر BYOC. لاحظ أن الخدمات قيد التشغيل تعمل بشكل مستقل عن مستوى التحكم في ClickHouse: إذ لا يؤدي انقطاع مستوى التحكم إلى إيقاف الخدمات التي تعمل في حسابك. إذا كانت لديك أسئلة إضافية، فيُرجى التواصل مع [support@clickhouse.com](mailto:support@clickhouse.com).
</Accordion>