نشر مثيل SQL المدار الذي تم تمكينه بواسطة Azure Arc باستخدام أدوات Kubernetes
توضح هذه المقالة كيفية نشر Azure SQL Managed Instance ل Azure Arc باستخدام أدوات Kubernetes.
المتطلبات الأساسية
يجب أن تكون قد أنشأت وحدة تحكم بيانات بالفعل.
لإنشاء مثيل مدار من SQL باستخدام أدوات Kubernetes، ستحتاج إلى تثبيت أدوات Kubernetes. ستستخدم kubectl
الأمثلة في هذه المقالة ، ولكن يمكن استخدام أساليب مماثلة مع أدوات Kubernetes الأخرى مثل لوحة معلومات Kubernetes، oc
أو helm
إذا كنت على دراية بهذه الأدوات وKubernetes yaml/json.
نظرة عامة
لإنشاء مثيل مدار من SQL، تحتاج إلى:
- إنشاء سر Kubernetes لتخزين تسجيل دخول مسؤول النظام وكلمة المرور بأمان
- إنشاء مورد مخصص لمثيل SQL المدار استنادا
SqlManagedInstance
إلى تعريف المورد المخصص
حدد كلا العنصرين في ملف yaml.
إنشاء ملف yaml
استخدم ملف yaml للقالب كنقطة بداية لإنشاء ملف yaml لمثيل SQL المدار المخصص الخاص بك. قم بتنزيل هذا الملف إلى الكمبيوتر المحلي وافتحه في محرر نصوص. استخدم محرر نص مثل VS Code الذي يدعم تمييز بناء الجملة وlinting لملفات yaml.
إشعار
بدءا من إصدار فبراير 2022، ReadWriteMany
يجب تحديد فئة التخزين القادرة على (RWX) للنسخ الاحتياطية. تعرف على المزيد حول أوضاع الوصول.
إذا لم يتم تحديد فئة تخزين للنسخ الاحتياطية، يتم استخدام فئة التخزين الافتراضية في Kubernetes. إذا لم يكن الافتراضي قادرا على RWX، فقد لا ينجح تثبيت مثيل SQL المدار.
مثال على ملف yaml
راجع المثال التالي لملف yaml:
apiVersion: v1
data:
password: <your base64 encoded password>
username: <your base64 encoded username>
kind: Secret
metadata:
name: sql1-login-secret
type: Opaque
---
apiVersion: sql.arcdata.microsoft.com/v12
kind: SqlManagedInstance
metadata:
name: sql1
annotations:
exampleannotation1: exampleannotationvalue1
exampleannotation2: exampleannotationvalue2
labels:
examplelabel1: examplelabelvalue1
examplelabel2: examplelabelvalue2
spec:
dev: true #options: [true, false]
licenseType: LicenseIncluded #options: [LicenseIncluded, BasePrice]. BasePrice is used for Azure Hybrid Benefits.
tier: GeneralPurpose #options: [GeneralPurpose, BusinessCritical]
security:
adminLoginSecret: sql1-login-secret
scheduling:
default:
resources:
limits:
cpu: "2"
memory: 4Gi
requests:
cpu: "1"
memory: 2Gi
services:
primary:
type: LoadBalancer
storage:
#backups:
# volumes:
# - className: azurefile # Backup volumes require a ReadWriteMany (RWX) capable storage class
# size: 5Gi
data:
volumes:
- className: default # Use default configured storage class or modify storage class based on your Kubernetes environment
size: 5Gi
datalogs:
volumes:
- className: default # Use default configured storage class or modify storage class based on your Kubernetes environment
size: 5Gi
logs:
volumes:
- className: default # Use default configured storage class or modify storage class based on your Kubernetes environment
size: 5Gi
تخصيص تسجيل الدخول وكلمة المرور
يتم تخزين سر Kubernetes كسلسلة مشفرة base64 - واحدة لاسم المستخدم وواحدة لكلمة المرور. ستحتاج إلى ترميز base64 لتسجيل دخول مسؤول النظام وكلمة المرور ووضعهما في موقع العنصر النائب في data.password
و data.username
. لا تقم بتضمين <
الرموز و >
المتوفرة في القالب.
إشعار
للحصول على الأمان الأمثل، لا يسمح باستخدام القيمة sa
لتسجيل الدخول .
اتبع نهج تعقيد كلمة المرور.
يمكنك استخدام أداة عبر الإنترنت لترميز اسم المستخدم وكلمة المرور المطلوبين base64 أو يمكنك استخدام أدوات CLI اعتمادا على النظام الأساسي الخاص بك.
بوويرشيل
[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('<your string to encode here>'))
#Example
#[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('example'))
Linux/macOS
echo -n '<your string to encode here>' | base64
#Example
# echo -n 'example' | base64
تخصيص الاسم
يحتوي القالب على قيمة sql1
لسمة الاسم. يمكنك تغيير هذه القيمة، ولكن يجب أن تتضمن أحرفا تتبع معايير تسمية DNS. يجب عليك أيضا تغيير اسم السر لمطابقته. على سبيل المثال، إذا قمت بتغيير اسم مثيل SQL المدار إلى sql2
، يجب تغيير اسم السر من sql1-login-secret
إلى sql2-login-secret
تخصيص متطلبات الموارد
يمكنك تغيير متطلبات الموارد - ذاكرة الوصول العشوائي والحدود والطلبات الأساسية - حسب الحاجة.
إشعار
يمكنك معرفة المزيد حول إدارة موارد Kubernetes.
متطلبات حدود الموارد والطلبات:
- قيمة حد الذاكرات الأساسية مطلوبة لأغراض الفوترة.
- بقية طلبات الموارد وحدودها اختيارية.
- يجب أن يكون حد الذاكرات الأساسية والطلب قيمة عدد صحيح موجب، إذا تم تحديده.
- مطلوب حد أدنى من ذاكرة أساسية واحدة لطلب الذاكرات الأساسية، إذا تم تحديده.
- يتبع تنسيق قيمة الذاكرة تدوين Kubernetes.
- مطلوب 2 غيغابايت كحد أدنى لطلب الذاكرة، إذا تم تحديده.
- كإرشادات عامة، يجب أن يكون لديك 4 غيغابايت من ذاكرة الوصول العشوائي لكل ذاكرة أساسية واحدة لحالات استخدام الإنتاج.
تخصيص نوع الخدمة
يمكن تغيير نوع الخدمة إلى NodePort إذا رغبت في ذلك. سيتم تعيين رقم منفذ عشوائي.
تخصيص التخزين
يمكنك تخصيص فئات التخزين للتخزين لمطابقة بيئتك. إذا لم تكن متأكدا من فئات التخزين المتوفرة، فقم بتشغيل الأمر kubectl get storageclass
لعرضها.
يحتوي القالب على قيمة افتراضية ل default
.
على سبيل المثال
storage:
data:
volumes:
- className: default
يعني هذا المثال أن هناك فئة تخزين تسمى default
- وليس أن هناك فئة تخزين هي الافتراضية. يمكنك أيضا تغيير حجم التخزين اختياريا. لمزيد من المعلومات، راجع تكوين التخزين.
إنشاء مثيل SQL المدار
الآن بعد أن قمت بتخصيص ملف yaml لمثيل SQL المدار، يمكنك إنشاء مثيل SQL المدار عن طريق تشغيل الأمر التالي:
kubectl create -n <your target namespace> -f <path to your yaml file>
#Example
#kubectl create -n arc -f C:\arc-data-services\sqlmi.yaml
مراقبة حالة الإنشاء
سيستغرق إنشاء مثيل SQL المدار بضع دقائق لإكماله. يمكنك مراقبة التقدم المحرز في نافذة طرفية أخرى باستخدام الأوامر التالية:
إشعار
تفترض أوامر المثال أدناه أنك قمت بإنشاء مثيل SQL مدار باسم sql1
ومساحة اسم Kubernetes بالاسم arc
. إذا استخدمت اسما مختلفا لمساحة اسم/مثيل مدار من SQL، يمكنك استبدال arc
و sqlmi
بأسماء.
kubectl get sqlmi/sql1 --namespace arc
kubectl get pods --namespace arc
يمكنك أيضا التحقق من حالة إنشاء أي جراب معين. شغّل kubectl describe pod ...
. استخدم هذا الأمر لاستكشاف أي مشكلات وإصلاحها. على سبيل المثال:
kubectl describe pod/<pod name> --namespace arc
#Example:
#kubectl describe pod/sql1-0 --namespace arc
استكشاف مشاكل التوزيع وإصلاحها
إذا واجهت أي مشكلات في النشر، فيرجى الاطلاع على دليل استكشاف الأخطاء وإصلاحها.
المحتوى ذو الصلة
الملاحظات
https://aka.ms/ContentUserFeedback.
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجعإرسال الملاحظات وعرضها المتعلقة بـ