الشيء الوحيد غير الواضح هو معنى الحرف "P". عندما يتم تقسيم الكتلة ، فإنها تقرر ما إذا كانت ستستجيب حتى يتم الوصول إلى النصاب القانوني ، أو إعطاء البيانات التي هي. اعتمادًا على نتائج هذا الاختيار ، يتم تصنيف النظام على أنه CP أو AP. كاساندرا ، على سبيل المثال ، يمكن أن تتصرف بهذه الطريقة وذاك ، ليس اعتمادًا حتى على إعدادات الكتلة ، ولكن على معلمات كل طلب محدد. ولكن إذا كان النظام ليس "P" وانقسم ، فماذا بعد؟
الإجابة على هذا السؤال غير متوقعة إلى حد ما: لا يمكن تقسيم مجموعة CA.
ما هي هذه الكتلة التي لا يمكن تقسيمها؟
السمة التي لا غنى عنها لمثل هذا التجمع هي نظام تخزين البيانات المشترك. في الغالبية العظمى من الحالات ، يعني هذا الاتصال عبر شبكة SAN ، مما يحد من استخدام حلول CA للمؤسسات الكبيرة التي يمكنها استضافة بنية SAN الأساسية. لكي تتمكن الخوادم المتعددة من العمل مع نفس البيانات ، يلزم وجود نظام ملفات مجمع. توجد أنظمة الملفات هذه في حافظات HPE (CFS) و Veritas (VxCFS) و IBM (GPFS).
Oracle RAC
ظهر خيار مجموعة التطبيقات الحقيقية لأول مرة في إصدار 2001 من Oracle 9i. في نظام مجموعة مثل أن مثيلات الخادم المتعددة تعمل مع نفس قاعدة البيانات.
يمكن أن تعمل Oracle مع كل من نظام ملفات الكتلة والحل الخاص بها - ASM ، إدارة التخزين التلقائي.
كل نسخة تحتفظ بمجلة خاصة بها. يتم تنفيذ الصفقة وتنفيذها في حالة واحدة. في حالة فشل المثيل ، تقرأ إحدى عقد المجموعة (المثيلات) الباقية سجلها وتستعيد البيانات المفقودة ، وبالتالي ضمان التوافر.
تحتفظ جميع المثيلات بذاكرة التخزين المؤقت الخاصة بها ، ويمكن أن تكون نفس الصفحات (الكتل) في وقت واحد في ذاكرة التخزين المؤقت لمثيلات متعددة. علاوة على ذلك ، إذا كانت هناك حاجة لصفحة من خلال مثيل واحد ، وكانت موجودة في ذاكرة التخزين المؤقت لمثيل آخر ، فيمكنها الحصول عليها من "الجار" باستخدام آلية دمج ذاكرة التخزين المؤقت بدلاً من القراءة من القرص.
ولكن ماذا يحدث إذا احتاجت إحدى الحالات إلى تغيير البيانات؟
تكمن خصوصية Oracle في أنها لا تحتوي على خدمة قفل مخصصة: إذا كان الخادم يريد قفل صف ، فسيتم وضع سجل القفل مباشرة على صفحة الذاكرة حيث يوجد الصف المقفل. هذا النهج يجعل Oracle بطلة الأداء لقاعدة البيانات المتجانسة: خدمة القفل لا تصبح أبدًا عنق الزجاجة. ولكن في التكوين العنقودي ، يمكن أن تؤدي هذه البنية إلى حركة مرور كثيفة على الشبكة وحالات توقف تام.
بمجرد حظر أحد السجلات ، يقوم المثيل بإعلام جميع المثيلات الأخرى بأن الصفحة التي تخزن السجل قد تم الحصول عليها في الوضع الخاص. إذا احتاج مثيل آخر إلى تغيير سجل في نفس الصفحة ، فيجب عليه الانتظار حتى يتم تنفيذ التغييرات على الصفحة ، أي ، تتم كتابة معلومات التغيير في سجل القرص (ويمكن أن تستمر المعاملة). قد يحدث أيضًا أن يتم تغيير الصفحة بالتسلسل بعدة نسخ ، وبعد ذلك ، عند كتابة الصفحة على القرص ، سيتعين عليك معرفة من لديه الإصدار الحالي من هذه الصفحة.
يؤدي تحديث نفس الصفحات عن طريق الخطأ عبر عقد RAC المختلفة إلى تدهور أداء قاعدة البيانات بشكل كبير - لدرجة أن أداء الكتلة يمكن أن يكون أبطأ من مثيل واحد.
الاستخدام الصحيح لـ Oracle RAC هو تقسيم البيانات فعليًا (على سبيل المثال ، باستخدام آلية الجدول المقسم) والوصول إلى كل مجموعة من الأقسام من خلال عقدة مخصصة. لم يكن الغرض الرئيسي من RAC هو القياس الأفقي ، ولكن التسامح مع الخطأ.
إذا توقفت العقدة عن الاستجابة لضربات القلب ، فإن العقدة التي تكتشفها تبدأ أولاً في إجراء التصويت على القرص. إذا لم تتم الإشارة إلى العقدة المفقودة هنا ، فستتولى إحدى العقد مسؤولية استعادة البيانات:
- "يجمد" جميع الصفحات التي كانت في ذاكرة التخزين المؤقت للعقدة المفقودة ؛
- يقرأ سجلات (إعادة) العقدة المفقودة ويعيد تطبيق التغييرات المسجلة في هذه السجلات ، مع التحقق مما إذا كانت العقد الأخرى لديها إصدارات أحدث من الصفحات التي تم تغييرها ؛
- يتراجع عن المعاملات غير الملتزمة.
لتبسيط التبديل بين العقد ، لدى Oracle مفهوم الخدمة - مثيل افتراضي. يمكن للمثيل أن يخدم خدمات متعددة ، ويمكن للخدمة أن تنتقل بين العقد. يعمل مثيل التطبيق الذي يخدم جزءًا معينًا من القاعدة (على سبيل المثال ، مجموعة من العملاء) مع خدمة واحدة ، وتنتقل الخدمة المسؤولة عن هذا الجزء من القاعدة ، عند فشل العقدة ، إلى عقدة أخرى.
IBM Pure Data Systems للمعاملات
ظهر الحل العنقودي لنظام إدارة قواعد البيانات في محفظة Blue Giant في عام 2009. من الناحية الأيديولوجية ، فهو وريث مجموعة Parallel Sysplex المبنية على الأجهزة "التقليدية". في عام 2009 ، تم إصدار DB2 pureScale كمجموعة برامج ، وفي عام 2012 تقدم IBM جهازًا يسمى Pure Data Systems for Transactions. لا ينبغي الخلط بينه وبين Pure Data Systems for Analytics ، وهو ليس أكثر من Netezza المعاد تسميته.
تبدو بنية pureScale للوهلة الأولى مثل Oracle RAC: بالطريقة نفسها ، يتم توصيل عدة عقد بنظام تخزين مشترك ، وتقوم كل عقدة بتشغيل مثيلها الخاص من DBMS بمناطق الذاكرة الخاصة بها وسجلات المعاملات. ولكن بخلاف Oracle ، فإن DB2 لديها خدمة قفل مخصصة ممثلة بمجموعة عمليات db2LLM *. في تكوين الكتلة ، يتم وضع هذه الخدمة على عقدة منفصلة ، والتي تسمى مرفق الاقتران (CF) في Parallel Sysplex ، و PowerHA في Pure Data.
يوفر PowerHA الخدمات التالية:
- مدير القفل
- ذاكرة التخزين المؤقت العالمية ؛
- مجال الاتصالات بين العمليات.
يتم استخدام الوصول إلى الذاكرة عن بُعد لنقل البيانات من PowerHA إلى عقد قاعدة البيانات والعكس صحيح ، لذلك يجب أن يدعم الاتصال البيني للمجموعة بروتوكول RDMA. يمكن أن يستخدم PureScale كلاً من Infiniband و RDMA عبر Ethernet.
إذا احتاجت العقدة إلى صفحة ، ولم تكن هذه الصفحة موجودة في ذاكرة التخزين المؤقت ، فإن العقدة تطلب صفحة في ذاكرة التخزين المؤقت العامة ، وإذا لم تكن هناك ، فإنها تقرأها من القرص. بخلاف Oracle ، ينتقل الاستعلام إلى PowerHA فقط وليس إلى العقد المجاورة.
إذا كان المثيل على وشك تغيير السلسلة ، فإنه يحظرها في الوضع الحصري ، والصفحة التي توجد بها السلسلة في الوضع المشترك. يتم تسجيل جميع الأقفال في مدير القفل العالمي. عند اكتمال المعاملة ، ترسل العقدة رسالة إلى مدير القفل ، الذي ينسخ الصفحة التي تم تغييرها في ذاكرة التخزين المؤقت العامة ، ويحرر الأقفال ، ويلغي صلاحية الصفحة التي تم تغييرها في ذاكرات التخزين المؤقت للعقد الأخرى.
إذا كانت الصفحة التي تحتوي على السلسلة المعدلة مقفلة بالفعل ، فسيقوم مدير القفل بقراءة الصفحة المعدلة من ذاكرة العقدة التي أجرت التغييرات ، وتحرير القفل ، وإلغاء صلاحية الصفحة المعدلة في ذاكرات التخزين المؤقت للعقد الأخرى ، وإعطاء قفل الصفحة للعقدة التي طلبت ذلك.
قذرة ، أي تغييرها ، يمكن كتابة الصفحات على القرص من عقدة عادية ومن PowerHA (castout).
إذا فشلت إحدى عقد PureScale ، فإن الاسترداد يقتصر فقط على تلك المعاملات التي لم تكتمل بعد في وقت الفشل: الصفحات التي تم تعديلها بواسطة تلك العقدة في المعاملات المكتملة موجودة في ذاكرة التخزين المؤقت العالمية على PowerHA. تتم إعادة تشغيل العقدة في تكوين تم تجريده على أحد خوادم الكتلة ، وتتراجع عن المعاملات غير الملتزمة وتصدر الأقفال.
يتم تشغيل PowerHA على خادمين وتقوم العقدة الرئيسية بتكرار حالتها بشكل متزامن. إذا فشلت عقدة PowerHA الأساسية ، تستمر الكتلة في العمل مع عقدة الاستعداد.
بالطبع ، إذا قمت بالوصول إلى مجموعة البيانات من خلال عقدة واحدة ، فسيكون أداء الكتلة الكلي أفضل. قد تلاحظ PureScale أن بعض مناطق البيانات تتم معالجتها بواسطة عقدة واحدة ، ومن ثم ستتم معالجة جميع الأقفال المتعلقة بهذه المنطقة محليًا بواسطة العقدة دون الاتصال بـ PowerHA. ولكن بمجرد أن يحاول التطبيق الوصول إلى هذه البيانات من خلال عقدة أخرى ، ستستأنف معالجة القفل المركزي.
تُظهر معايير IBM الداخلية عند قراءة 90٪ و 10٪ عبء عمل للكتابة ، وهي تشبه إلى حد بعيد أعباء عمل الإنتاج الحقيقية ، تحجيمًا خطيًا تقريبًا يصل إلى 128 عقدة. شروط الاختبار ، للأسف ، لم يتم الكشف عنها.
HPE NonStop SQL
تمتلك مجموعة Hewlett-Packard Enterprise أيضًا منصة خاصة بها عالية التوفر. هذه هي منصة NonStop التي تم إطلاقها في عام 1976 بواسطة Tandem Computers. في عام 1997 ، استحوذت شركة Compaq على الشركة ، والتي اندمجت بدورها مع Hewlett-Packard في عام 2002.
يُستخدم NonStop لبناء تطبيقات مهمة - على سبيل المثال ، HLR أو معالجة البطاقة المصرفية. يتم تسليم النظام الأساسي في شكل مجمع برامج وأجهزة (جهاز) ، والذي يتضمن عقد الحوسبة ونظام تخزين البيانات ومعدات الاتصال. يخدم ServerNet (في الأنظمة الحديثة - Infiniband) كلاً من التبادل بين العقد والوصول إلى نظام تخزين البيانات.
استخدمت الإصدارات السابقة من النظام معالجات خاصة تمت مزامنتها مع بعضها البعض: تم تنفيذ جميع العمليات بشكل متزامن من قبل عدة معالجات ، وبمجرد أن أخطأ أحد المعالجات ، تم إيقاف تشغيله ، واستمر الثاني في العمل. في وقت لاحق ، تحول النظام إلى المعالجات التقليدية (MIPS أولاً ، ثم Itanium ، وأخيراً x86) ، وبدأ استخدام الآليات الأخرى للمزامنة:
- الرسائل: لكل عملية نظام توأم "ظل" ، ترسل إليه العملية النشطة بشكل دوري رسائل حول حالتها ؛ إذا فشلت العملية الرئيسية ، تبدأ عملية الظل في العمل من اللحظة التي تحددها الرسالة الأخيرة ؛
- : , , ; , /.
منذ عام 1987 ، تم تشغيل DBMS علائقي على النظام الأساسي NonStop - أول SQL / MP ، ولاحقًا SQL / MX.
تنقسم قاعدة البيانات بأكملها إلى أجزاء ، وكل جزء مسؤول عن عملية إدارة الوصول إلى البيانات (DAM) الخاصة به. يوفر آلية كتابة البيانات والتخزين المؤقت والقفل. تتم معالجة معالجة البيانات بواسطة Executor Server Process ، والتي تعمل على نفس العقد مثل مديري البيانات المعنيين. يقوم برنامج جدولة SQL / MX بتقسيم المهام بين المنفذين ودمج النتائج. إذا كنت بحاجة إلى إجراء تغييرات متسقة ، فاستخدم بروتوكول الالتزام ذي المرحلتين الذي توفره مكتبة TMF (تسهيل إدارة المعاملات).
يمكن لـ NonStop SQL تحديد أولويات العمليات بحيث لا تتداخل الاستعلامات التحليلية الطويلة مع تنفيذ المعاملات. ومع ذلك ، فإن الغرض منه هو على وجه التحديد معالجة المعاملات القصيرة ، وليس التحليلات. يضمن المطور توفر مجموعة NonStop بمستوى خمس تسعات ، أي أن وقت التوقف عن العمل هو 5 دقائق فقط في السنة.
ساب هانا
تم إصدار أول إصدار مستقر من HANA DBMS (1.0) في نوفمبر 2010 ، وانتقلت حزمة SAP ERP إلى HANA في مايو 2013. تعتمد المنصة على التقنيات المشتراة: محرك بحث TREX (البحث في التخزين العمودي) ، P * TIME و MAX DB.
كلمة "HANA" نفسها هي اختصار ، جهاز تحليلي عالي الأداء. يتم تسليم DBMS هذا في شكل كود يمكن تشغيله على أي خوادم x86 ، ومع ذلك ، لا يُسمح بالتركيبات الصناعية إلا على المعدات المعتمدة. هناك حلول من HP و Lenovo و Cisco و Dell و Fujitsu و Hitachi و NEC. تسمح بعض تكوينات Lenovo بالتشغيل بدون SAN - تلعب مجموعة GPFS على الأقراص المحلية دور التخزين المشترك.
على عكس الأنظمة الأساسية المذكورة أعلاه ، فإن HANA عبارة عن DBMS في الذاكرة ، أي يتم تخزين الصورة الأساسية للبيانات في ذاكرة الوصول العشوائي ، ويتم كتابة السجلات واللقطات الدورية فقط على القرص لاستردادها في حالة وقوع كارثة.
كل عقدة في كتلة HANA مسؤولة عن الجزء الخاص بها من البيانات ، ويتم تخزين مخطط البيانات في مكون خاص - خادم الأسماء ، الموجود في عقدة المنسق. لا يتم تكرار البيانات بين العقد. يتم تخزين معلومات القفل أيضًا على كل عقدة ، لكن النظام يحتوي على كاشف توقف تام عالمي.
يقوم عميل HANA ، عند الاتصال بالعنقود ، بتحميل الهيكل الخاص به ويمكنه في المستقبل الوصول مباشرة إلى أي عقدة ، اعتمادًا على البيانات التي يحتاجها. إذا كانت هناك معاملة تؤثر على بيانات عقدة واحدة ، فيمكن تنفيذها بواسطة هذه العقدة محليًا ، ولكن إذا تغيرت بيانات عدة عقد ، فإن عقدة البادئ تتصل بعقدة المنسق ، التي تفتح وتنسق المعاملة الموزعة ، وتنفذها باستخدام بروتوكول الالتزام المحسن ثنائي المرحلة.
يتم تكرار عقدة المنسق ، لذلك إذا فشل المنسق ، فستتولى عقدة النسخ الاحتياطي فورًا. ولكن إذا فشلت عقدة بها بيانات ، فإن الطريقة الوحيدة للوصول إلى بياناتها هي إعادة تشغيل العقدة. كقاعدة عامة ، في مجموعات HANA يتم الاحتفاظ بخادم احتياطي لإعادة تشغيل العقدة المفقودة عليها في أقرب وقت ممكن.