هل تميز Oracle بين فئات الخدمة المختلفة، مثل الخدمات الحيوية أو الخدمات المتاحة المستمرة أو خدمات الموقع الواحد؟

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

مستويات التبعية

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

من الأسفل إلى الأعلى:

• الخدمات الأساس: تشكل هذه الخدمات أساس Oracle Cloud Infrastructure. وهي تتضمن إدارة الهوية والوصول (IAM)، وإدارة المفاتيح، والشبكات، والحوسبة، وأحجام الكتل، وتخزين الكائنات، ,القياس عن بعد، والعديد من الخدمات الداخلية المشتركة. إنها مصممة حتى تشتمل أقل قدر من التبعيات، حتى بين بعضها بعضًا. (راجع لاحقًا في هذا المستند للحصول على تفاصيل حول التبعيات).
• IaaS: توفر هذه الطبقة مزيدًا من الوظائف على مستوى البنية التحتية التي يتم إنشاؤها أعلى النواة. تشتمل الخدمات الموجودة في هذه الطبقة على؛ تخزين الملفات وقاعدة البيانات ومحرك حاويات Kubernetes.
• SaaS: تعد هذه الطبقة برنامج كخدمة غني مبنية على طبقات سفلية.

نطاق التوفر

لتحقيق أهداف التوفر والمتانة لخدمة ما، يتم اختيار أحد نطاقات التوفر التالية لكل خدمة:

• مجال التوفر المحلي: يحتوي كل نطاق توفر على مثيل مستقل واحد للخدمة. توفر هذه الخدمات متانة عالية للبيانات المخزنة باستخدام النسخ المتماثل المتزامن بين النُسخ المتماثلة في نفس نطاق التوفر (للحصول على التفاصيل، راجع القسم الخاص بنطاقات الخطأ لاحقًا في هذا المستند). ويمكن أن تتحمل هذه الخدمات انقطاعًا عن ثلث البنية التحتية أو أكثر في نطاق التوفر، وفقًا لطبيعة الخدمة. تحقق الخدمات المحلية لمجال التوفر هذا المستوى من احتمال الأخطاء باستخدام نوعين مختلفين من مركز البيانات المنطقي-المجموعات المنطقية لعزل الأخطاء وعزل الأداء—داخل نطاق التوفر. للحصول على تفاصيل، راجع الأقسام الموجودة في نطاقات الخطأ وخلايا الخدمة في هذا المستند لاحقًا. وأخيرًا، يمكن أن تستمر هذه الخدمات في العمل بشكل طبيعي حتى إذا لم يتمكن نطاق التوفر من الاتصال بأي نطاقات توفر أخرى. ونتيجة لذلك، فإنها تتسامح مع فقدان مجالات توفر أخرى أو الفشل الكامل للشبكة الواسعة النطاق داخل المنطقة.
• منطقة نطاق التوفر المتعددة: تحتوي كل منطقة ذات نطاقات توفر متعددة على مثيل مستقل واحد للخدمة، مع وجود مكونات في كل نطاق توفر في هذه المنطقة. توفر هذه الخدمات متانة عالية جدًا للبيانات المخزنة باستخدام النسخ المتماثل المتزامن لنطاقات التوفر المتعددة في نفس المنطقة. يمكن أن تتسامح هذه الخدمات مع انقطاع أو عدم القدرة على الاتصال بأي نطاق توفر واحد في المنطقة.
• منطقة نطاق التوفر الفردية: إذا كانت المنطقة تحتوي على نطاق توفر واحد فقط، فإن الخصائص التي يمكن ملاحظتها لخدمة إقليمية تطابق خصائص الخدمة المحلية لنطاق التوفر، كما هو موضح سابقًا. يصبح التمييز بين الخدمة المحلية لمجال التوفر والخدمة الإقليمية لمجال توفر واحد مناسبًا فقط عند توسيع منطقة نطاق توفر واحد بإضافة نطاق توفر واحد أو أكثر. عندما يحدث ذلك، تتوسع كل خدمة إقليمية تلقائيًا للاستفادة المناسبة من نطاقات التوفر الجديدة مع الاحتفاظ بمثيل واحد للخدمة. على سبيل المثال، يتم توسيع مستوى بيانات تخزين الكائنات لاستخدام نطاقات التوفر الإضافية لتحسين متانة البيانات الحالية. رغم ذلك، بالنسبة للخدمات المحلية لنطاق التوفر، يتلقى كل نطاق من نطاقات التوفر الجديدة مثيله الجديد والمستقل الخاص بكل خدمة محلية لنطاق التوفر.
• موزع عبر المناطق: مبدأ أساس لـ Oracle Cloud Infrastructure هو أن كل منطقة مستقلة عن المناطق الأخرى بقدر الإمكان. يعكس التأهيل كـ ممكن حقيقة أنه يجب على المناطق بالضرورة مشاركة بعض البنية التحتية على الأقل، على سبيل المثال، الشبكة الأساس بين المناطق. وإلا، فلن ننشئ آليات اقتران وثيقة بين المناطق، مثل توفر شفاف عالي أو تجاوز فشل، قد يسبب مشاكل تؤثر على مناطق متعددة في وقت واحد. بدلًا من ذلك، نقدم آليتين لتوزيع الخدمات عبر المناطق مع اقتران غير محكم:
  • إجراءات مواجهة الكوارث (DR): يُعد تمكين عملائنا من إنشاء أنظمة ذات خصائص DR حجر الزاوية في نهجنا واستثمارنا في السحابة. تقدم العديد من الخدمات الأساس آليات DR بالف��ل—على سبيل المثال، النسخ الاحتياطي لوحدات التخزين بين المناطق والنسخة المشتركة بين مناطق تخزين الكائنات. تتضمن جميع خدماتنا وظائف DR كأصناف ذات أولوية عالية في خارطة الطريق الخاصة بها.
  • الاشتراكات بين المناطق: نقدم حاليًا اشتراكات بين المناطق لبيانات IAM فحسب. من الناحية التصورية، تحتوي بيانات IAM على نطاق عالمي. يمكن للعملاء الاشتراك (المشاركة) في مجموعة من المناطق، كما نقوم تلقائيًا باستنساخ بيانات IAM ذات الصلة والتحديثات اللاحقة للمناطق المحددة. لتجنب الاقتران غير المحكم، يكون النسخ المتماثل غير متزامن وفي النهاية متسق. يقوم العملاء بإجراء تعديلات على بيانات IAM الخاصة بهم في منطقة "الصفحة الرئيسة" التي يرشحونها. إذا أصبحت المنطقة المحلية الحالية غير متاحة أو غير مناسبة لسبب ما، فيمكن ترشيح منطقة مختلفة.

لوحة التحكم مقابل لوحة البيانات

مستوى البيانات للخدمة هو مجموعة من واجهات ومكونات معالجة البيانات التي تنفذ وظيفة الخدمة التي تهدف إلى استخدامها بواسطة التطبيقات. على سبيل المثال، تتضمن مستوى بيانات شبكة السحابة الظاهرية (VCN) نظام معالجة حزم الشبكة وأجهزة التوجيه الافتراضية والبوابات، في حين أن مستوى بيانات وحدات تخزين الكتل يشتمل على تنفيذ بروتوكول iSCSI ونظام التخزين المتماثل للأخطاء لبيانات وحدة التخزين.

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

• معالجة طلبات العملاء لتوفير الموارد أو إعادة تكوينها أو توسيعها نطاقها أو خفضه أو إنهاؤها
• إجراء التصحيح الآلي للأساطيل الكبيرة، بسرعة وأمان
• اكتشاف الموارد الفاشلة أو المتدهورة أو التي لم يتم تكوينها بشكل صحيح
• إجراء الإصلاح الآلي، أو ترقيم مشغلين بشريين للحصول على المساعدة
• التعاون مع مستويات التحكم الأخرى (مثل الحوسبة، VCN، وتخزين الكتل المقترن خلال LaunchInstance)
• إدارة السعة غير المستخدمة
• التنسيق مع البشر، على سبيل المثال عند وصول معدات جديدة، والإصلاح المادي والصيانة
• توفير الرؤية التشغيلية والتحكم فيها

كيف تضمن Oracle مرونة الخدمات وتوفرها باستمرار؟

بالنسبة لجميع أنواع الخدمات ، نستخدم نفس مجموعة المبادئ الهندسية لتحقيق المرونة والتوفر ، لأن التحديات الهندسية الأساسية لبناء أنظمة تكون قادرة على تحمل الأخطاء وقابلة للتطوير وموزعة بذاتها لجميع أنواع الخدمة.

لتحقيق المرونة والتوفر المستمر، من الضروري فهم جميع أسباب الأداء عدم التوفر—وحالات الفشل غير المعالجة في الأنظمة—على نطاق السحابة، ثم التعامل معها. هناك عدد كبير من هذه الأسباب، لذلك نقوم بتجميعها في فئات وفقًا لطبيعتها الأساس

تقليديًا، ركز تحليل توفر أنظمة تكنولوجيا المعلومات المؤسسية على فئة فشل الأجهزة. ومع ذلك، بالنسبة للأنظمة السحابية، يعد فشل الأجهزة مشكلة بسيطة نسبيًا ومفهومة بشكل جيد. أصبح من السهل نسبيًا تجنب معظم نقاط فشل الأجهزة الفردية أو تخفيفها. على سبيل المثال، يمكن أن تحتوي الحوامل على تغذيات طاقة مزدوجة ووحدات توزيع طاقة مرتبطة بها، كما أن العديد من المكونات قابلة للتبديل دون إيقاف التشغيل. ففشل وفقدان الأجهزة على نطاق واسع أمر ممكن بالطبع—على سبيل المثال، بسبب الكوارث الطبيعية. مع ذلك، تُظهر تجربتنا وتقاريرنا في الرسائل اللاحقة العامة من موردي السحابة الآخرين، أن فشل أو فقدان مركز بيانات بأكمله يحدث بشكل كبير نادرًا، بالنسبة للأسباب الأخرى لعدم التوفر. ولا يزال يتعين التصدي لفشل الأجهزة على نطاق واسع (على سبيل المثال، مع استعادة القدرة على العمل بعد الكوارث وغيرها من الآليات)، ولكنه بعيد كل البعد عن كونه مشكلة التوفرالسائدة.

وفيما يلي الأسباب الرئيسة لعدم التوفر في النظم السحابية:

• أخطاء البرامج
• أخطاء التكوين
• الأخطاء التي ارتكبها المشغلون البشريون
  ملاحظة: الدرس الرئيس من الصناعة هو أن هذه الأشكال الثلاثة للخطأ البشري هي أكبر أسباب عدم التوفر إلى حد بعيد. على الرغم من إمكانية تقليل معدل تكرارها من خلال الأدوات والأتمتة والتدريب، إلا أنه لا يمكن إزالتها. لذلك، يجب التعامل معها باعتبارها المخاوف الرئيسة في بنية وتصميم وتنفيذ النظام.
• التباين غير المقبول في الأداء (زمن الانتقال أو الإنتاجية) لأي سبب، بما في ذلك الأسباب التالية:
  • متعدد العملاء "الجيران المزعجون" (فشل آليات QoS)
  • عدم القدرة على رفض الحمل الزائد بكفاءة (العرضي أو الضار) مع الاستمرار في القيام بعمل مفيد
  • التعطل الموزع ومشكلات الرسائل ومشكلات إعادة المحاولة والتفاعلات "الطارئة" الأخرى الباهظة الثمن
  • الصدمة الباردة (وحدات ذاكرة تخزين مؤقت فارغة) بعد دورة التشغيل، خاصة دورة التشغيل المتزامنة لأنظمة متعددة
  • المصروفات الإضافية عند قياس النظام (على سبيل المثال، إعادة التقسيم)
• عدم الحد من "نصف قطر الماضي" (عدد العملاء والأنظمة المتأثرة) لأي من المشكلات السابقة

هذه التحديات عامة—فهي جزء من "قوانين الفيزياء" للأنظمة الموزعة على نطاق السحابة.

بالنسبة لكل فئة من الفئات السابقة، نستخدم استراتيجيات هندسية مثبتة لمعالجة المشكلة. أهمها ما يلي:

• مبادئ البنية وتصميم النظام
• المفاهيم الهيكلية الجديدة (التي تنشأ عادة عن تطبيق المبادئ)
• إجراءات هندسة الخدمات

مبادئ البنية وتصميم النظام

يوجد العديد من هذه المبادئ، لكننا سنركز على تلك الأكثر صلة بالمرونة والتوفر.

الحوسبة الموجهة للاسترداد

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

يتمثل هدفنا في التعافي بسرعة حتى لا يخل المستخدمون البشريون بهذه المسألة. تساعدنا النقاط التالية على تحقيق هذا الهدف التالي:

• الكشف بسرعة وبشكل تلقائي عن أعراض الأخطاء التي يرتكبها المشغلون، من خلال الاستخدام الواسع للتأكيدات في التعليمات البرمجية، والرصد النشط والتنبيه على جميع المستويات.
• حزم الوظائف في العديد من وحدات العزل المستقلة الدقيقة (سلاسل العمليات والعمليات والألياف وأجهزة الحالة وما إلى ذلك) التي يتم اقترانها بشكل غير محكم—وهذا يعني أنها لا تشارك الذاكرة بشكل مباشر التي قد تصبح تالفة.
• عند اكتشاف أعراض خلل أو خطأ من قبل المشغل، قم بإعادة تشغيل وحدة العزل المضمنة تلقائيًا في أسرع وقت ممكن. إعادة التشغيل هي طريقة عملية لمحاولة التعافي من الفشل التعسفي، لأنها تحاول إعادة إنشاء حالة تم اختبارها بشكل جيد، وبالتالي استعادة المتغيرات.
• إذا لم ينجح الاسترداد على مستوى العزل الدقيق (على سبيل المثال، تستمر التأكيدات في التشغيل على هذا المستوى بشكل متكرر، مما يتسبب في انهيار الجولات)، والتصاعد إلى الوحدة الأكبر التالية (العملية، وقت التشغيل، المضيف، مركز البيانات المنطقي، ترقيم صفحات المشغل البشري).
• إنشاء آليات لتمكين "التراجع على مستوى النظام"، بما في ذلك تعيين إصدار لجميع الحالات والتكوينات الدائمة، من أجل تحديد عمليات التثبيت غير الصحيحة والتراجع عنها بسرعة.

الحد الأدنى من آثار المشكلات

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

المفاهيم الهيكلية الناشئة عن مبادئ التصميم

توجد العديد من هذه المفاهيم، لكننا نركز على مفاهيم للحد من نصف قطر الأعم.

مفاهيم الوضع المنصوص عليها في واجهة برمجة التطبيقات العامة: المناطق ونطاقات التوفر ونطاقات الأخطاء

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

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

يكمن الضمان في أنه في نطاق توفر معين، يتم تغيير الموارد في نطاق خطأ واحد على الأكثر في أي وقت. إذا حدث خطأ ما في عملية التغيير، فقد تكون بعض أو كل الموارد الموجودة في نطاق الخطأ هذا غير متاحة لفترة من الوقت، لكن لن تتأثر نطاقات الخطأ الأخرى في نطاق التوفر. يحتوي كل نطاق توفر على ثلاثة نطاقات خطأ على الأقل، للسماح باستضافة أنظمة النسخ المتماثل المستندة إلى النصاب (على سبيل المثال، Oracle Data Guard) مع توفر عالٍ في نطاق توفر واحد.

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

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

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

تستخدم خدماتنا الداخلية نطاقات الخطأ بنفس الطريقة التي يجب أن يستخدمها العملاء. على سبيل المثال، تخزن وحدات تخزين الكتل وتخزين الكائنات وتخزين الملفات النسخ المتماثلة للبيانات في ثلاثة نطاقات أخطاء منفصلة. تتم استضافة جميع مكونات كل مستويات التحكم ومستويات البيانات في جميع نطاقات الأخطاء الثلاثة (أو في منطقة نطاق توفر متعددة في نطاقات توفر متعددة).

خلايا الخدمة

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

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

لاحظ أن استخدام خلايا الخدمة هو نمط هيكلي، ليس مفهوم مسمى صراحة في Oracle Cloud API أو SDK. يمكن لأي نظام متعدد المؤسسات استخدام هذا النمط الهيكلي؛ ولا يتطلب دعمًا خاصًا من المنصة السحابية.

تعمل خلايا الخدمة كما يلي:

• يتكون كل مثيل من الخدمة (على سبيل المثال، في منطقة معينة أو في نطاق توفر معين للخدمات المحلية لنطاق التوفر) من عمليات نشر متعددة منفصلة لمجموعة برامج الخدمة. تسمى كل عملية نشر منفصلة خلية. تتم استضافة كل خلية على بنيتها التحتية الخاصة بقدر ما تكون عملية. لا تشارك الخلايا كحد أدنى المضيفين أو الأجهزة الظاهرية.
• قد تبدأ الخدمة بمجموعة من الخلايا في كل نطاق أو منطقة توفر. مع توسع الخدمة لتلبية الطلب المتزايد، تتم إضافة المزيد من الخلايا للحفاظ على الحد من حجم نصف قطر الانفجار لأي مشاكل. قد تحتوي الخدمة المعروفة الكبيرة على العديد من الخلايا. وبعبارة أخرى، توفر الخلايا تعدد أحمال عمل العملاء من n إلى m لفصل بيئات الاستضافة—فصل جزر عزل الموارد. لا تحتوي الخلايا على الأعداد الرئيسة hgواضحة، مثل الموجودة لنطاقات الخطأ. (كما ذُكر سابقًا، فإن الاختيار الواضح للأعداد الرئيسة لنطاقات الخطأ هو ثلاثة لكل نطاق توفر، من أجل تمكين استضافة أنظمة النسخ المماثل المستندة إلى النِصاب مع توفر عالٍ في نطاق توفر واحد.)
• يتم تعيين كل "وحدة طبيعية" لحمل عمل العميل إلى خلية معينة. يعتمد تعريف "الوحدة الطبيعية" على طبيعة الخدمة المعينة. على سبيل المثال، بالنسبة لخدمة سير العمل المشتركة الداخلية (الموضحة لاحقًا)، قد تكون الوحدة الطبيعية هي "كل عمليات سير العمل في نطاق التوفر هذا أو المنطقة لمستوى تحكم معين".
• أمام كل مجموعة من الخلايا إما طبقة توجيه بحد أدنى أو واجهة برمجة تطبيقات لاكتشاف نقاط انتهاء الخلية. على سبيل المثال، يحتوي نظام البث/المراسلة على واجهة برمجة تطبيقات لاكتشاف نقطة انتهاء مستوى البيانات الحالي لموضوع معين، ويحتوي مخزن بيانات التعريف الداخلي على نقطة ��نتهاء منفصلة لكل خلية. على أي حال، لدى الخدمات الأخرى القائمة على الخلايا نقطة نهاية لمستوى بيانات واحد وطبقة توجيه مشتركة. تعتبر طبقة التوجيه سببًا محتملًا للفشل المرتبط لخلايا متعددة، ولكن يتم التخفيف من ذلك عن طريق الحفاظ على طبقة التوجيه بسيطة للغاية ويمكن التنبؤ بها وتكون عالية الأداء (بدون عمليات باهظة التكلفة)، وتوفيرها بكمية كبيرة من سعة غرفة العناوين وآليات الحصص QoS المتطورة والتقييد.
• يمكن لمالكي الخدمة نقل حمل العمل من خلية إلى أخرى، حسب الحاجة. فيما يلي بعض الأمثلة على السيناريوهات:
  • للمساعدة على تجنب مشكلة "الجار المزعج" متعددة العملاء عن طريق نقل حمل عمل ثقيل حتى لا يتأثر المستخدمون الآخرون للخلية.
  • للمساعدة في التعافي من الحمل الزائد أو البنية، ربما بسبب هجوم رفض الخدمة الموزع. لدينا آليات للحصص والتقييد للدفاع ضد مثل هذه الهجمات، ولكن في بعض الأحيان تحدث حالات استثنائية تكون فيها حالة استخدام معينة (API، نمط الوصول) أكثر صرامة للخدمة من نظام الحصص أو التقييد يفهم حاليًا. توفر الخلايا آلية لتخفيف المخاطر على المدى القصير.
  • لفصل أحمال العمل المهمة إلى خلايا مختلفة، لتقليل احتمالية الفشل المرتبط بشكل كبير. على سبيل المثال، بالنسبة لدفق الأعمال المشترك الداخلي الخاص بنا لمستويات التحكم، يتم تعيين كل من مستويات التحكم "النواة الحرجة" (على سبيل المثال، المنصة والحوسبة والشبكات وأحجام الكتل) إلى خلايا مختلفة، وبالتالي يكون ارتباط الفشل أقل بكثير مما لو لم يتم استخدام الخلايا، أو تم تعيينها إلى نفس الخلية.
    ملاحظة: يقلل استخدام الخلايا هذا من الحاجة إلى أن يضع العملاء في الاعتبار التبعيات الداخلية للخدمات من أجل إنشاء تطبيقات مرنة. بالنظر إلى أن الرسم البياني للتبعية لا يزال ممارسة جيدة (أكثر على ذلك في وقت لاحق في هذا المستند)، ولكن ثمة حاجة أقل لذلك عندما تكون آلية فك الترابط نشطة بالفعل.

تعد النتيجة هي أن كل خلية خدمة نوع آخر من "مركز البيانات المنطقي"—وهو تجميع منطقي لعزل الأداء وعزل الأخطاء—داخل نطاق أو منطقة توفر واحدة.

باختصار، تكمل خلايا الخدمة ونطاقات الخطأ بعضها بعضًا بالطرق التالية:

• تحمي نطاقات الخطأ من المشكلات عند تغيير النظام بشكل نشط.
• تحد خلايا الخدمة نصف قطر الانفجار عندما يواجه النظام مشكلات محتملة الخطورة—سواء تم تغييره فعليًا أم لا.

نجمع بين خصائص مجالات الخطأ وخلايا الخدمة في استراتيجية موحدة عند إجراء عمليات النشر والتصحيح.

إجراءات هندسة الخدمة

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

• ننشر الخدمات بشكل تزايدي مع التحقق الدقيق بين الخطوات وإلغاء التعديلات العكسية إذا حدث أي شيء مفاجئ. من الناحية العملية، تكون العملية كما يلي:
  • في كل مجال من مجالات التوفر، ننشر إلى خلية خدمة واحدة في كل مرة. بالنسبة لكل خلية، ننشر نطاق خطأ واحد في كل مرة، حتى نكمل جميع نطاقات الخطأ الخاصة بتلك الخلية. وبعد ذلك، نتقدم إلى الخلية التالية في مجال التوفر هذا.
  • بعد كل خطوة من خطوات النشر (بعد كل مجال وخلية خطأ)، نتحقق من أن التغيير يعمل كما هو مقصود—أي أننا لم نخفض الأداء أو أدخلنا أية أخطاء، داخلية أو خارجية. إذا بدا أن أي شيء خاطئًا أو غير متوقع، فسنعيد تعديلات التغيير بشكل متزامن. نركز بشكل كبير على إعداد إجراءات إلغاء التعديلات واختبارها، بما في ذلك الاختبارات التلقائية، بما في ذلك التغييرات التي تؤثر على الحالة الثابتة أو المخططات.
  • وبهذه الطريقة، ننشر تغيير نطاق توفر واحد في المرة الواحدة لكل منطقة. ننشر في جميع المناطق في نطاق بطريقة لا نعدل في الوقت نفسه أي زوج من المناطق التي قد يستخدمها العميل لمواقع استعادة البيانات الأولية والكوارث.
• نتحقق بانتظام من أن آليات معالجة الأخطاء وغيرها من التخفيف تعمل على النحو المتوقع ولا تجعل المشكلة أسوأ على نطاق واسع. بدون مثل هذا الاختبار، من الشائع أن تحتوي آليات معالجة الأخطاء (مثل إعادة المحاولة، وخوارزميات استرداد التعطل، وخوارزميات إعادة تكوين جهاز الولاية) على أخطاء أو تكون مكلفة للغاية أو تتفاعل بطرق مدهشة، وبالتالي تسبب مشاكل في الأداء الخطيرة الموزعة أو غيرها.
• نتحقق من قدرتنا على التراجع بسرعة وأمان إلى آخر برامج وتكوين جيدة معروفة، بما في ذلك الحالة الثابتة والمخطط، كما هو موضح سابقًا.

في مناطق Oracle التي تحتوي على نطاقات توفر متعددة، هل يتم توزيع جميع الخدمات المهمة عبر نطاقات التوفر؟

نعم. في كل منطقة، توفر جميع نطاقات التوفر نفس مجموعة الخدمات.

كيف تتجنب Oracle وعملائها امتلاك خدمة بالغة الأهمية تعتمد على مركز بيانات منطقي واحد؟

في مناطق مجال التوفر الواحدة، يمكن للعملاء استخدام نطاقات الأخطاء (مجموعات منطقية ذات أوضاع فشل مرتبطة بالديكور بين المجموعات) لتحقيق معظم خصائص "مراكز البيانات المنطقية" المنفصلة. يمكن للعملاء أيضًا استخدام مناطق متعددة لاستعادة البيانات بعد الكوارث (DR).

في مناطق مجال التوفر المتعددة، يمكن للعملاء استخدام نطاقات الأخطاء بنفس الطريقة. يمكن للعملاء أيضًا استخدام مزيج من الخدمات المحلية لنطاق التوفر، وميزات تجاوز الفشل بين نطاقات التوفر (مثل DBaaS مع Data Guard)، والخدمات الإقليمية (تخزين الكائنات، والتدفق) لتحقيق التوفر العالي الكامل عبر "مراكز البيانات المنطقية" عالية المستوى (نطاقات التوفر). وأخيرًا، يمكن للعملاء أيضًا استخدام مناطق متعددة لإجراءات مواجهة الكوارث.

في جميع الحالات، يمكن للعملاء استخدام مفهوم خلايا الخدمة لزيادة عزل حتى أكثر المشكلات حدة، مثل التعطل الموزع.

كيف تنفذ Oracle أنشطة الصيانة دون جعل أي خدمة هامة غير متوفرة مؤقتًا لأي عميل؟

نحقق ذلك من خلال نطاقات الأخطاء وخلايا الخدمة وإجراءاتنا التشغيلية للنشر التدريجي والتحقق. عرض المناقشة السابقة في هذا المستند.

هل يتم نشر خدمات المنصة بدون خادم عبر مراكز بيانات منطقية متعددة لزيادة التوفر؟

نعم. يتم نشر جميع فئات الخدمات عبر مراكز بيانات منطقية متعددة—فصل المجموعات المنطقية لعزل الأخطاء وعزل الأداء—من أجل المرونة والتوفر المستمر.

إذا لم تكن المرونة هي التكوين الافتراضي، فهل يقدم العملاء خيارًا لنشر مركز بيانات منطقي متعدد (على سبيل المثال، تكوين مجال متوفر متعدد أو متعدد المناطق)؟

في مناطق نطاق التوفر الواحدة، نقدم نطاقات الأخطاء كآلية لـ "مراكز البيانات المنطقية المتعددة"، كما هو موضح في موضع آخر في هذه الوثيقة.

في مناطق ذات نطاقات متعددة التوفر، نقدم الخدمات والميزات التي توفر مستوى أعلى من المتانة المادية للبيانات المتماثلة بشكل متزامن (بأداء متواضع، وتكلفة بسبب المسافة بين مجالات التوفر في المنطقة، وسرعة الضوء).

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

كيف تساعد Oracle العملاء على تجنب الفشل المرتبط بالتطبيقات الناتجة عن التبعيات الداخلية بين مختلف خدمات البنية التحتية والمنصة؟

هذا سؤال معقد، للتوضيح، سنعيد طرحه بعدة طرق مختلفة:

• إذا أراد أحد العملاء استخدام خدمتين من خدمات Oracle (الخدمة أ والخدمة ب) وكان يريد إنشاء تطبيق يتسم بالمرونة في حالة فشل أي من هاتين الخدمتين، فهل يحتاج العميل إلى معرفة ما إذا كانت الخدمة أ تعتمد داخليًا على الخدمة ب؟ هل تؤدي التبعيات الداخلية إلى فشل مرتبط بدرجة كبيرة؟ إذا كان الأمر كذلك، فقد يحتاج العميل إلى معرفة هذه التبعيات الداخلية، من أجل تحديد الاستخدامات الأخرى لتقديم الخدمة أ والخدمة ب—أو بدلًا من ذلك سحب خدمة جـ غير ذات الصلة بتلك الحالات الإضافية—عند بناء آليات المرونة على مستوى التطبيق.
• كيف يمكن للعميل الدفاع بأفضل وجه ضد أي فشل مرتبط بخدمات Oracle؟

تأتي الإجابة في جزأين.

المبادئ الهيكيلة

نستخدم المبادئ الهيكلية التي تقلل بشكل كبير من الفشل المرتبط عبر الخدمات التابعة. في بعض الحالات، تقلل هذه التقنية من احتمال الفشل المرتبط إلى درجة يمكن تجاهلها من منظور الوفاء باتفاقية مستوى خدمة التوفر (SLA).

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

العديد من خدماتنا الداخلية المشتركة—على سبيل المثال، خدمات سير العمل والميتاديتا لطائرات التحكم، وخلايا خدمة البث / الرسائل—تستخدم لتزيين الانقطاعات المؤقتة للخدمات السابقة التي تستخدمها.

التبعيات

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

بالنسبة إلى مستويات التحكم، تكون التبعيات العامة كما يلي:

• مستوى بيانات النظام الأساس/الهوية للتصديق والاعتماد
• خدمة تتبع المراجعة
• الخدمات الداخلية التي توفر، على سبيل المثال، سير العمل وتخزين بيانات التعريف والتسجيل
• موازنات تحميل الأنواع المختلفة

لدى بعض مستويات التحكم تبعيات خاصة بالخدمة. على سبيل المثال، يعتمد مستوى التحكم في الحوسبة، عند تشغيل طبعة نظام تشغيل أو جهاز ظاهري، على ما يلي:

• تخزين الكائنات (لاسترجاع صورة نظام التشغيل المحددة)
• مستوى التحكم في وحدات تخزين الكتل (لإعداد وحدة تخزين التمهيد وربطها)
• مستوى التحكم في الشبكات (لإعداد شبكات VNIC وربطها)

بالنسبة لمستويات بيانات الخدمات الأساس، المبدأ العام هو أن كل مستوى بيانات مصمم عمداً للحصول على أقل قدر من التبعيات، من أجل تحقيق التوفر العالي، والوقت السريع للتشخيص، والوقت السريع للانتعاش. فيما يلي نتائج ذلك المبدأ:

• يعد مستوى بيانات الشبكات مستقل.
• يعد مستوى بيانات وحدات تخزين الكتل مستقل.
• تعتمد مثيلات الحوسبة المخصصة ومثيلات الأجهزة الظاهرية على مستوى بيانات وحدات تخزين الكتل (لوحدات تخزين التمهيد) ومستوى بيانات الشبكات.
• يعتمد مستوى بيانات تخزين الكائنات على مستوى بيانات الهوية/المنصة للتصديق والاعتماد (بسبب توقعات المجال). لا يعتمد مستوى بيانات تخزين الكائنات على وحدات تخزين الكتل أو تخزين الملفات.
• تعتمد جميع الخدمات التي تدعم النسخ الاحتياطي والاستعادة على مستوى بيانات تخزين الكائنات لتلك الميزة.

بالنسبة لمستويات بيانات IaaS، يعتمد المبدأ العام فقط على مستويات البيانات الأساس أو المنخفضة (من أجل تجنب التبعيات الدورية).

• تعتمد قاعدة البيانات ذات نقاط توصيل متعددة على مستوى بيانات الشبكات ومستوى بيانات وحدات تخزين الكتل.
• يعتمد محرك حاويات Kubernetes بشكل واضح على نظام Kubernetes وتبعياته الانتقالية (على سبيل المثال، etcd) ومستوى بيانات الشبكات.
• يعتمد دعم النسخ الاحتياطي والاستعادة على مستوى بيانات مخزن الكائنات.

هل تستمر خدمات Oracle Cloud Infrastructure في المنطقة، بما في ذلك نقاط انتهاء واجهة برمجة التطبيقات الإقليمية، في العمل إذا كانت معزولة عن وظائف مستوى التحكم العام؟

نعم، تم تصميم خدمات Oracle Cloud Infrastructure لتكون مستقلة عن المنطقة حتى تستمر الخدمات في منطقة Oracle Cloud Infrastructure في العمل حتى عندما تكون المنطقة معزولة عن مناطق Oracle Cloud Infrastructure الأخرى و/أو مستوى التحكم العام. تظل وظائف مستوى البيانات ومستوى التحكم، بما في ذلك نقاط نهاية واجهة برمجة تطبيقات الخدمة، متوفرة حتى في حالة عزل المنطقة.

توفر العديد من خدمات Oracle Cloud Infrastructure وظائف عبر المناطق مثل وظيفة نسخ الكائنات عبر المناطق التي توفرها Oracle Cloud Infrastructure Object Storage. دائمًا تتم صياغة الوظائف عبر المناطق في Oracle Cloud Infrastructure كطبقة في أعلى الخدمة الأساس حتى لا تؤثر عزلة المنطقة على الخدمة الأساس حتى إذا كانت تؤثر على وظائف المناطق المختلفة. على سبيل المثال، يتم تصميم وظيفة النسخ عبر المناطق لمخزن كائنات Oracle Cloud Infrastructure كطبقة على أعلى خدمة مخزن الكائنات وبالتالي، قد تؤثر عزل المنطقة على وظيفة النسخ المتقاطع ذات الصلة، ولكنها لن تؤثر على خدمة تخزين الكائنات الأساس في المنطقة.

هل تستمر خدمات Oracle Cloud Infrastructure في مركز بيانات منطقي في العمل إذا كانت معزولة عن وظائف مستوى التحكم الإقليمي؟

نعم، يتم تصميم خدمات Oracle Cloud Infrastructure إذ تستمر وظيفة مستوى البيانات في كل مركز بيانات منطقي في العمل حتى عند عزلها عن مستوى التحكم الإقليمي المقابل. على سبيل المثال، تستمر مثيلات حوسبة Oracle Cloud Infrastructure في مركز بيانات منطقي في العمل جنبًا إلى جنب مع وحدات تخزين الكتل المرفقة ووظائف الشبكة الظاهرية المرتبطة بها حتى عندما يتم عزل مركز البيانات عن وظائف مستوى التحكم للحوسبة وتخزين الكتل و/أو VCN و/أو إدارة الهوية والوصول.

هل تحتوي مناطق Oracle Cloud Infrastructure على اتصالات إنترنت زائدة للتوفر العالي؟

نعم. تتصل Oracle Cloud Infrastructure بالإنترنت عبر العديد من موفري الخدمة المتكررين في كل المناطق التجارية. تستخدم هذه الاتصالات BGP (بروتوكول البوابة الحدودية).