مشاركة عبر

إرشادات التحجيم

  • مقالة

نظرة عامة على إرشادات التحجيم

عند التخطيط لتوزيع خدمات بيانات Azure Arc، خطط للكمية الصحيحة من:

  • Compute
  • الذاكرة
  • التخزين

هذه الموارد مطلوبة من أجل:

  • وحدة تحكم البيانات
  • مثيلات SQL المُدارة
  • خوادم PostgreSQL

نظرا لأن خدمات البيانات التي تدعم Azure Arc يتم نشرها على Kubernetes، لديك المرونة في إضافة المزيد من السعة إلى مجموعة Kubernetes بمرور الوقت عن طريق حساب العقد أو التخزين. يشرح هذا الدليل الحد الأدنى من المتطلبات ويوصي بأحجام لبعض المتطلبات الشائعة.

متطلبات التحجيم العامة

إشعار

إذا لم تكن على دراية بالمفاهيم الواردة في هذه المقالة، يمكنك قراءة المزيد بشأن إدارة موارد Kubernetes و رمز حجم Kubernetes.

يجب أن تكون أرقام الذاكرات الأساسية قيمة عدد صحيح أكبر من أو تساوي واحداً.

عند النشر باستخدام Azure CLI (az)، استخدم قوة رقمين لتعيين قيم الذاكرة. على وجه التحديد، استخدم اللاحقات:

  • Ki
  • Mi
  • Gi

يجب أن تكون قيم الحد دائماً أكبر من قيمة الطلب، إذا تم تحديدها.

قيم الحد للذاكرات الأساسية هي المقياس القابل للفوترة على مثيل SQL المدار وخوادم PostgreSQL.

الحد الأدنى من متطلبات التوزيع

يمكن اعتبار نشر خدمات البيانات التي تدعم Azure Arc الحد الأدنى للحجم ليكون وحدة تحكم بيانات Azure Arc بالإضافة إلى مثيل SQL مدار واحد بالإضافة إلى خادم PostgreSQL واحد. لهذا التكوين، تحتاج إلى ذاكرة وصول عشوائي بسعة 16 غيغابايت على الأقل و4 ذاكرات أساسية من السعة المتوفرة على مجموعة Kubernetes الخاصة بك. يجب عليك التأكد من أن لديك الحد الأدنى لحجم عقدة Kubernetes من ذاكرة الوصول العشوائي 8 غيغابايت و4 ذاكرات أساسية وسعة إجمالية تبلغ 16 غيغابايت متوفرة عبر جميع عقد Kubernetes. على سبيل المثال، يمكن أن يكون لديك عقدة واحدة بذاكرة وصول عشوائي بسعة 32 غيغابايت و4 ذاكرات أساسية أو يمكن أن يكون لديك عقدتان بذاكرة وصول عشوائي بسعة 16 غيغابايت و4 ذاكرات أساسية لكل منهما.

راجع مقالة storage-configuration للحصول على تفاصيل بشأن حجم التخزين.

تفاصيل تحجيم وحدة التحكم في البيانات

وحدة التحكم في البيانات عبارة عن مجموعة من وحدات pod التي يتم توزيعها في مجموعة Kubernetes الخاصة بك لتوفير واجهة برمجة تطبيقات وخدمة وحدة التحكم وbootstrapper وقواعد بيانات المراقبة ولوحات المعلومات. يصف هذا الجدول القيم الافتراضية لطلبات وحدود الذاكرة ووحدة المعالجة المركزية.

اسم وحدة pod طلب وحدة المعالجة المركزية طلب الذاكرة حد المعالج حد الذاكرة
bootstrapper 100m 100Mi 200m 200Mi
control 400m 2Gi 1800m 2Gi
controldb 200m 4Gi 800m 6Gi
logsdb 200m 1600Mi 2 1600Mi
logsui 100m 500Mi 2 2Gi
metricsdb 200m 800Mi 400m 2Gi
metricsdc 100m 200Mi 200m 300Mi
metricsui 20m 200Mi 500m 200Mi

metricsdcdaemonsetهو ، الذي يتم إنشاؤه على كل عقدة من عقد Kubernetes في نظام المجموعة الخاص بك. الأرقام في الجدول لكل عقدة. إذا قمت بتعيين allowNodeMetricsCollection = false في ملف تعريف التوزيع قبل إنشاء وحدة تحكم البيانات، فلن يتم إنشاء هذا daemonset .

يمكنك تجاوز الإعدادات الافتراضية لوحدات controldb الجراب والتحكم في ملف YAML لوحدة تحكم البيانات. مثال:

  resources:
    controller:
      limits:
        cpu: "1000m"
        memory: "3Gi"
      requests:
        cpu: "800m"
        memory: "2Gi"
    controllerDb:
      limits:
        cpu: "800m"
        memory: "8Gi"
      requests:
        cpu: "200m"
        memory: "4Gi"

راجع مقالة storage-configuration للحصول على تفاصيل بشأن حجم التخزين.

SQL تفاصيل تحجيم المثيل المُدار

يجب أن يحتوي كل مثيل مُدار من SQL على الحد الأدنى لطلبات وحدود الموارد التالية:

مستوى الخدمة General Purpose Business Critical
طلب وحدة المعالجة المركزية الحد الأدنى: 1
الحد الأقصى: 24
الافتراضي: 2		 الحد الأدنى: 3
الحد الأقصى: غير محدود
الافتراضي: 4
حد المعالج الحد الأدنى: 1
الحد الأقصى: 24
الافتراضي: 2		 الحد الأدنى: 3
الحد الأقصى: غير محدود
الافتراضي: 4
طلب الذاكرة الحد الادني: 2Gi
الحد الاقصي: 128Gi
الافتراضي: 4Gi		 الحد الادني: 2Gi
الحد الأقصى: غير محدود
الافتراضي: 4Gi
حد الذاكرة الحد الادني: 2Gi
الحد الاقصي: 128Gi
الافتراضي: 4Gi		 الحد الادني: 2Gi
الحد الأقصى: غير محدود
الافتراضي: 4Gi

تحتوي كل وحدة pod مثيل مُدار بواسطة SQL تم إنشاؤه على ثلاث حاويات:

اسم الحاوية طلب وحدة المعالجة المركزية طلب الذاكرة حد وحدة المعالجة المركزية حد الذاكرة ملاحظات
fluentbit 100m 100Mi غير محدد غير محدد fluentbit طلبات موارد الحاوية بالإضافة إلى الطلبات المحددة لمثيل SQL المدار.
arc-sqlmi مستخدم محدد أم غير محدد. مستخدم محدد أم غير محدد. مستخدم محدد أم غير محدد. مستخدم محدد أم غير محدد.
collectd غير محدد غير محدد غير محدد غير محدد

حجم وحدة التخزين الافتراضي لكافة وحدات التخزين الثابتة هو 5Gi.

تفاصيل تغيير حجم خادم PostgreSQL

يجب أن يكون لكل عقدة خادم PostgreSQL الحد الأدنى من طلبات الموارد التالية:

  • الذاكرة: 256Mi
  • ذاكرة أساسية: 1

يحتوي كل جراب خادم PostgreSQL تم إنشاؤه على ثلاث حاويات:

اسم الحاوية طلب وحدة المعالجة المركزية طلب الذاكرة حد وحدة المعالجة المركزية حد الذاكرة ملاحظات
fluentbit 100m 100Mi غير محدد غير محدد fluentbit طلبات موارد الحاوية بالإضافة إلى الطلبات المحددة لخادم PostgreSQL.
postgres مستخدم محدد أم غير محدد. المستخدم المحدد أو 256Mi (افتراضي). مستخدم محدد أم غير محدد. مستخدم محدد أم غير محدد.
arc-postgresql-agent غير محدد غير محدد غير محدد غير محدد

الحجم التراكمي

الحجم الإجمالي لبيئة مطلوبة لخدمات البيانات التي تدعم Azure Arc هو في المقام الأول دالة لعدد وحجم مثيلات قاعدة البيانات. قد يكون من الصعب التنبؤ بالحجم الإجمالي مسبقا مع العلم أن عدد المثيلات قد يزداد ويتقلص ويمكن أن يتغير مقدار الموارد المطلوبة لكل مثيل قاعدة بيانات.

حجم الأساس لبيئة خدمات بيانات معينة ممكنة بواسطة Azure Arc هو حجم وحدة تحكم البيانات، والذي يتطلب 4 ذاكرات أساسية وذاكرة وصول عشوائي بسعة 16 غيغابايت. من هناك، أضف الإجمالي التراكمي للذاكرات الأساسية والذاكرة المطلوبة لمثيلات قاعدة البيانات. يتطلب مثيل SQL المدار حاوية واحدة لكل مثيل. ينشئ خادم PostgreSQL حاوية واحدة لكل خادم.

بالإضافة إلى الذاكرات الأساسية والذاكرة التي تطلبها لكل مثيل قاعدة بيانات، يجب إضافة 250m الذاكرات الأساسية وذاكرة 250Mi الوصول العشوائي لحاويات العامل.

مثال على حساب تغيير الحجم

المتطلبات:

  • "SQL1": مثيل SQL مدار بذاكرة وصول عشوائي بسعة 16 غيغابايت، و4 ذاكرات أساسية
  • "SQL2": مثيل SQL مدار مع ذاكرة وصول عشوائي 256 غيغابايت، 16 ذاكرة أساسية
  • "Postgres1": خادم PostgreSQL 1 بذاكرة وصول عشوائي بسعة 12 غيغابايت، و4 ذاكرات أساسية

حسابات التحجيم:

  • حجم "SQL1" هو: 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). بالنسبة للوكلاء لكل جراب، استخدم 16.25 Gi ذاكرة الوصول العشوائي و4.25 نواة.

  • حجم "SQL2" هو: 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). بالنسبة للوكلاء لكل جراب، استخدم 256.25 Gi ذاكرة الوصول العشوائي و16.25 نواة.

  • الحجم الإجمالي ل SQL 1 وSQL 2 هو:

    • (16.25 GB + 256.25 Gi) = 272.5-GB RAM
    • (4.25 cores + 16.25 cores) = 20.5 cores

  • حجم "Postgres1" هو: 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). بالنسبة للوكلاء لكل جراب، استخدم 12.25 Gi ذاكرة الوصول العشوائي والذاكرات 4.25 الأساسية.

  • السعة الإجمالية المطلوبة:

    • بالنسبة لمثيلات قاعدة البيانات:
      • ذاكرة وصول عشوائي بسعة 272.5 غيغابايت
      • 20.5 نواة
    • بالنسبة إلى SQL:
      • ذاكرة وصول عشوائي بسعة 12.25 غيغابايت
      • 4.25 نواة
    • لخادم PostgreSQL
      • ذاكرة وصول عشوائي 284.75 غيغابايت
      • 24.75 نواة

  • السعة الإجمالية المطلوبة لمثيلات قاعدة البيانات بالإضافة إلى وحدة تحكم البيانات هي:

    • لمثيل قاعدة البيانات
      • ذاكرة وصول عشوائي 284.75 غيغابايت
      • 24.75 نواة
    • لوحدة تحكم البيانات
      • ذاكرة وصول عشوائي بسعة 16 غيغابايت
      • 4 ذاكرات أساسية
    • إجمالا:
      • ذاكرة وصول عشوائي بسعة 300.75 غيغابايت
      • 28.75 نواة.

راجع مقالة storage-configuration للحصول على تفاصيل بشأن حجم التخزين.

اعتبارات أخرى

ضع في اعتبارك أن طلب حجم مثيل قاعدة البيانات المحدد للذاكرة الأساسية أو ذاكرة الوصول العشوائي لا يمكن أن يتجاوز السعة المتاحة لعقد Kubernetes في المجموعة. على سبيل المثال، إذا كانت أكبر عقدة Kubernetes لديك في مجموعة Kubernetes الخاصة بك هي ذاكرة وصول عشوائي بسعة 256 غيغابايت و24 ذاكرة أساسية، فلا يمكنك إنشاء مثيل قاعدة بيانات بطلب ذاكرة وصول عشوائي 512 غيغابايت و48 ذاكرة أساسية.

الحفاظ على ما لا يقل عن 25٪ من السعة المتاحة عبر عقد Kubernetes. تسمح هذه السعة ل Kubernetes ب:

  • جدولة الجرابات التي سيتم إنشاؤها بكفاءة
  • تمكين التحجيم المرن
  • يدعم الترقيات المتداولة لعقد Kubernetes
  • تسهيل النمو على المدى الطويل حسب الطلب

في حسابات التحجيم الخاصة بك، أضف متطلبات الموارد الخاصة بقرون نظام Kubernetes وأي أحمال عمل أخرى، والتي قد تكون مشاركة السعة مع خدمات البيانات التي تدعم Azure Arc على نفس مجموعة Kubernetes.

للحفاظ على قابلية الوصول العالية أثناء الصيانة المخطط لها واستمرارية الكوارث، خطط لإحدى عقد Kubernetes على الأقل في مجموعتك لتكون غير متوفرة في أي نقطة زمنية معينة. يحاول Kubernetes إعادة جدولة القرون التي كانت تعمل على عقدة معينة تم إيقافها للصيانة أو بسبب فشل. إذا لم تكن هناك سعة متوفرة على العقد المتبقية، فلن تتم إعادة جدولة هذه القرون للإنشاء حتى تتوفر السعة مرة أخرى. كن حذراً للغاية مع مثيلات قاعدة البيانات الكبيرة. على سبيل المثال، إذا كان هناك عقدة Kubernetes واحدة فقط كبيرة بما يكفي لتلبية متطلبات الموارد لمثيل قاعدة بيانات كبير وفشلت تلك العقدة، فلن يقوم Kubernetes بجدولة حاوية مثيل قاعدة البيانات هذه على عقدة Kubernetes أخرى.

ضع في اعتبارك الحدود القصوى لحجم مجموعة Kubernetes.

ربما يكون مسؤول Kubernetes قد قام بإعداد حصص موارد على مساحة الاسم/المشروع. ضع هذه الحصص النسبية في الاعتبار عند التخطيط لأحجام مثيلات قاعدة البيانات.