عدد كبير من تطبيقات المؤسسات وأنظمة المحاكاة الافتراضية لها آلياتها الخاصة لبناء حلول تتسامح مع الأخطاء. على وجه التحديد ، Oracle RAC (Oracle Real Application Cluster) عبارة عن مجموعة مكونة من اثنين أو أكثر من خوادم قاعدة بيانات Oracle التي تعمل معًا لتوفير موازنة الحمل والتسامح مع الخطأ على مستوى الخادم / التطبيق. للعمل في هذا الوضع ، أنت بحاجة إلى مساحة تخزين مشتركة ، والتي عادة ما تكون نظام التخزين.
كما ناقشنا بالفعل في أحد أعمالنا ، نظام التخزين نفسه ، على الرغم من وجود مكونات مكررة (بما في ذلك وحدات التحكم) ، لا يزال لديه نقاط فشل - بشكل أساسي في شكل مجموعة بيانات واحدة. لذلك ، من أجل بناء حل Oracle مع متطلبات متزايدة للوثوقية ، يجب أن يكون مخطط "N server - one storage" معقدًا.
أولاً ، بالطبع ، نحتاج إلى تحديد المخاطر التي نحاول التأمين ضدها. في إطار هذا المقال ، لن نفكر في الحماية من تهديدات مثل "نيزك قد وصل". لذلك سيظل بناء حل للتعافي من الكوارث مشتتًا جغرافيًا موضوعًا لأحد المقالات التالية. هنا سننظر في ما يسمى بحل التعافي من الكوارث عبر الرف ، عندما يتم بناء الحماية على مستوى خزانات الخادم. يمكن وضع الخزانات نفسها في نفس الغرفة وفي غرف مختلفة ، ولكن عادةً داخل نفس المبنى.
يجب أن تحتوي هذه الخزانات على كل المجموعة الضرورية من الأجهزة والبرامج التي ستسمح لقواعد بيانات Oracle بالعمل بغض النظر عن حالة "الجار". بعبارة أخرى ، باستخدام حل Cross-Rack للتعافي من الكوارث ، فإننا نتخلص من مخاطر الفشل:
- خوادم تطبيقات أوراكل
- أنظمة التخزين
- أنظمة التحويل
- فشل كامل لجميع المعدات في الخزانة:
- الحرمان من الطعام
- فشل نظام التبريد
- العوامل الخارجية (الإنسان ، الطبيعة ، إلخ.)
ينطوي تكرار خوادم أوراكل على مبدأ تشغيل Oracle RAC ويتم تنفيذه من خلال التطبيق. ازدواجية مرافق التحويل ليست مشكلة أيضًا. ولكن مع ازدواجية نظام التخزين ، كل شيء ليس بهذه البساطة.
الخيار الأسهل هو نسخ البيانات من نظام التخزين الرئيسي إلى نظام النسخ الاحتياطي. متزامن أو غير متزامن ، حسب إمكانيات التخزين. مع النسخ غير المتزامن ، يطرح السؤال على الفور لضمان اتساق البيانات فيما يتعلق بأوراكل. ولكن حتى في حالة وجود تكامل برمجي مع التطبيق ، على أي حال ، في حالة حدوث عطل في نظام التخزين الرئيسي ، فإن التدخل اليدوي من قبل المسؤولين سيكون مطلوبًا من أجل تبديل الكتلة إلى تخزين النسخ الاحتياطي.
هناك خيار أكثر تعقيدًا وهو "المحاكاة الافتراضية" للبرامج و / أو الأجهزة لأنظمة التخزين التي ستقضي على مشاكل الاتساق والتدخل اليدوي. لكن تعقيد النشر والإدارة اللاحقة ، فضلاً عن التكلفة غير اللائقة لمثل هذه الحلول ، تردع الكثيرين.
فقط لسيناريوهات مثل Cross-Rack لاستعادة الكوارث ، فإن مصفوفة AccelStor NeoSapphire ™ All Flash مثالية باستخدام هندسة لا شيء مشترك. هذا النموذج هو نظام تخزين ثنائي العقد يستخدم تقنية FlexiRemap® الخاصة للعمل مع محركات أقراص فلاش. شكرا ل NeoSapphire™ H710 قادر على تقديم أداء يصل إلى 600K IOPS@4K للكتابة العشوائية و1M+ IOPS@4K للقراءة العشوائية، وهو أمر لا يمكن تحقيقه عند استخدام أنظمة التخزين التقليدية القائمة على RAID.
لكن الميزة الرئيسية لـ NeoSapphire ™ H710 هي تنفيذ عقدتين في شكل حالات منفصلة ، لكل منها نسختها الخاصة من البيانات. تتم مزامنة العقد من خلال واجهة InfiniBand الخارجية. بفضل هذه البنية ، من الممكن نشر العقد إلى مواقع مختلفة على مسافة تصل إلى 100 متر ، وبالتالي توفير حل Cross-Rack للتعافي من الكوارث. تعمل كلا العقدتين بشكل كامل في الوضع المتزامن. من جانب المضيفين ، يبدو H710 وكأنه نظام تخزين عادي ثنائي التحكم. لذلك ، لا يلزم تنفيذ أي خيارات برامج وأجهزة إضافية ولا سيما الإعدادات المعقدة.
إذا قارنا جميع حلول التعافي من الكوارث عبر الرف أعلاه ، فإن الإصدار من AccelStor يبرز عن البقية:
بنية لا شيء مشترك AccelStor NeoSapphire ™
تخزين البرامج أو الأجهزة
حل قائم على النسخ المتماثل
توفر
فشل الخادم
لا توقف
لا توقف
لا توقف
فشل التبديل
لا توقف
لا توقف
لا توقف
فشل التخزين
لا توقف
لا توقف
التوقف
فشل مجلس الوزراء بأكمله
لا توقف
لا توقف
التوقف
التكلفة والتعقيد
تكلفة الحل
قليل*
Высокая
Высокая
تعقيد النشر
منخفض
Высокая
Высокая
* لا يزال AccelStor NeoSapphire ™ عبارة عن مصفوفة All Flash ، والتي ، بحكم تعريفها ، لا تكلف "3 كوبيل" ، لا سيما امتلاكها سعة تخزين مزدوجة. ومع ذلك ، عند مقارنة التكلفة النهائية لأحد الحلول التي تستند إليها بتكلفة مماثلة من بائعين آخرين ، يمكن اعتبار التكلفة منخفضة.
سيبدو الهيكل الخاص بتوصيل خوادم وعقد التطبيقات الخاصة بمصفوفة All Flash كما يلي:
عند التخطيط للطوبولوجيا ، يوصى بشدة بتكرار محولات الإدارة والوصلات البينية للخادم.
فيما يلي ، سنتحدث عن الاتصال عبر القناة الليفية. في حالة استخدام بروتوكول iSCSI ، سيكون كل شيء كما هو ، ويتم تعديله وفقًا لأنواع المفاتيح المستخدمة وإعدادات الصفيف المختلفة قليلاً.
العمل التحضيري على المصفوفة
الأجهزة والبرامج المستخدمة
مواصفات الخادم والتبديل
مكونات
وصف
خوادم Oracle Database 11g
اثنان
نظام تشغيل الخادم
أوراكل لينكس
إصدار قاعدة بيانات أوراكل
11 جرام (RAC)
معالجات لكل خادم
اثنان من 16 نواة Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
الذاكرة الفعلية لكل خادم
128GB
شبكة FC
16Gb / s FC مع متعدد المسارات
إف سي إتش بي إيه
ايمولكس Lpe-16002B
منافذ إيثرنت 1 جيجابت عامة مخصصة لإدارة المجموعة
محول إيثرنت إنتل RJ45
16Gb / s FC التبديل
بروكار 6505
منافذ إيثرنت 10 جيجابت خاصة مخصصة لمزامنة البيانات
إنتل X520
AccelStor NeoSapphhire ™ جميع مواصفات صفيف الفلاش
مكونات
وصف
نظام التخزين
طراز التوفر العالي NeoSapphire ™: H710
نسخة الصورة
4.0.1
العدد الإجمالي لمحركات الأقراص
48
حجم محرك الأقراص
1.92TB
نوع الدفع
SSD
منافذ FC المستهدفة
16 منافذ 16 جيجا بايت (8 لكل عقدة)
منافذ الإدارة
كابل إيثرنت 1 جيجابت متصل بالمضيفين عبر محول إيثرنت
منفذ نبضات القلب
كابل إيثرنت 1 جيجابت يربط بين عقدتي تخزين
منفذ مزامنة البيانات
كابل InfiniBand 56 جيجابت / ثانية
قبل استخدام المصفوفة ، يجب تهيئتها. بشكل افتراضي ، يكون عنوان التحكم لكلا العقدتين هو نفسه (192.168.1.1). تحتاج إلى الاتصال بهم واحدًا تلو الآخر وتعيين عناوين إدارة جديدة (مختلفة بالفعل) وإعداد مزامنة الوقت ، وبعد ذلك يمكن توصيل منافذ الإدارة بشبكة واحدة. بعد ذلك ، يتم دمج العقد في زوج HA عن طريق تخصيص شبكات فرعية لوصلات Interlink.
بعد اكتمال التهيئة ، يمكنك إدارة المصفوفة من أي عقدة.
بعد ذلك ، نقوم بإنشاء المجلدات اللازمة ونشرها على خوادم التطبيق.
يوصى بشدة بإنشاء وحدات تخزين متعددة لـ Oracle ASM ، حيث سيؤدي ذلك إلى زيادة عدد الأهداف للخوادم ، مما سيؤدي في النهاية إلى تحسين الأداء العام (المزيد في قوائم الانتظار في أخرى ).
تكوين الاختبار
اسم وحدة التخزين
حجم الصوت
Data01
200GB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
إعادة 01
100GB
إعادة 02
100GB
إعادة 03
100GB
إعادة 04
100GB
إعادة 05
100GB
إعادة 06
100GB
إعادة 07
100GB
إعادة 08
100GB
إعادة 09
100GB
إعادة 10
100GB
بعض التفسيرات حول أنماط تشغيل المصفوفة والعمليات الجارية في حالات الطوارئ
تحتوي كل مجموعة بيانات خاصة بالعقدة على معلمة "رقم الإصدار". بعد التهيئة الأولية ، يكون هو نفسه ويساوي 1. إذا كان رقم الإصدار مختلفًا لسبب ما ، فستتم مزامنة البيانات دائمًا من الإصدار الأقدم إلى الإصدار الأصغر ، وبعد ذلك يتم معادلة الرقم للإصدار الأصغر ، أي. هذا يعني أن النسخ متطابقة. أسباب اختلاف الإصدارات:
- إعادة التشغيل المجدولة لإحدى العقد
- حادث في إحدى العقد بسبب الإغلاق المفاجئ (التيار ، السخونة الزائدة ، إلخ).
- فقد اتصال InfiniBand مع عدم القدرة على المزامنة
- حادث على إحدى العقد بسبب تلف البيانات. سيتطلب هذا بالفعل إنشاء مجموعة HA جديدة والمزامنة الكاملة لمجموعة البيانات.
في كلتا الحالتين ، تزيد العقدة التي تظل متصلة برقم إصدارها بمقدار واحد بحيث تتم مزامنة مجموعة البيانات الخاصة به عند استعادة الاتصال بالزوج.
إذا كان هناك انقطاع في الاتصال عبر ارتباط Ethernet ، فحينئذٍ يتحول Heartbeat مؤقتًا إلى InfiniBand ويعود في غضون 10 ثوانٍ عند استعادته.
إعداد المضيفين
للتسامح مع الخطأ وتحسين الأداء ، يجب تمكين دعم MPIO للصفيف. للقيام بذلك ، أضف أسطرًا إلى الملف /etc/multipath.conf ، ثم أعد تشغيل الخدمة متعددة المسارات
النص المخفيالأجهزة {
جهاز {
البائع "AStor"
path_grouping_policy "group_by_prio"
path_selector "طول قائمة الانتظار 0"
path_checker "تور"
ميزات "0"
معالج الأجهزة "0"
بريو "كونست"
الفشل الفوري
fast_io_fail_tmo 5
60
user_fri friendly_names نعم
كشف عن نعم
rr_min_io_rq 1
no_path_retry 0
}
}
بعد ذلك ، لكي تعمل ASM مع MPIO من خلال ASMLib ، تحتاج إلى تغيير ملف / etc / sysconfig / oracleasm ثم تشغيل /etc/init.d/oracleasm scandisks
النص المخفي
# ORACLESM_SCANORDER: مطابقة الأنماط لطلب مسح القرص
ORACLESM_SCANORDER = "dm"
# ORACLEASM_SCANEXCLUDE: مطابقة الأنماط لاستبعاد الأقراص من الفحص
ORACLEASM_SCANEXCLUDE = "sd"
لاحظ
إذا كنت لا ترغب في استخدام ASMLib ، فيمكنك استخدام قواعد UDEV ، والتي تعد أساس ASMLib.
بدءًا من الإصدار 12.1.0.2 من Oracle Database ، يتوفر الخيار للتثبيت كجزء من برنامج ASMFD.
تأكد من التأكد من أن الأقراص التي تقوم بإنشائها لـ Oracle ASM تتماشى مع حجم الكتلة التي تعمل بها المصفوفة فعليًا (4K). خلاف ذلك ، من الممكن حدوث مشاكل في الأداء. لذلك ، من الضروري إنشاء مجلدات باستخدام المعلمات المناسبة:
parted / dev / mapper / اسم الجهاز mklabel gpt mkpart basic 2048s 100٪ align-check optimal 1
توزيع قواعد البيانات عبر وحدات التخزين التي تم إنشاؤها لتكوين الاختبار الخاص بنا
اسم وحدة التخزين
حجم الصوت
تعيين حجم LUNs
تفاصيل جهاز حجم الصوت ASM
حجم وحدة التخصيص
Data01
200GB
تعيين جميع وحدات التخزين لنظام التخزين جميع منافذ البيانات
التكرار: عادي
الاسم: DGDATA
الغرض: ملفات البيانات
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
التكرار: عادي
الاسم: DGGRID1
الغرض: الشبكة: معيار الإبلاغ المشترك والتصويت
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
التكرار: عادي
الاسم: DGGRID2
الغرض: الشبكة: معيار الإبلاغ المشترك والتصويت
4MB
Grid05
1GB
Grid06
1GB
إعادة 01
100GB
التكرار: عادي
الاسم: DGREDO1
الغرض: إعادة سجل الخيط 1
4MB
إعادة 02
100GB
إعادة 03
100GB
إعادة 04
100GB
إعادة 05
100GB
إعادة 06
100GB
التكرار: عادي
الاسم: DGREDO2
الغرض: إعادة سجل الخيط 2
4MB
إعادة 07
100GB
إعادة 08
100GB
إعادة 09
100GB
إعادة 10
100GB
إعدادات قاعدة البيانات
- حجم الكتلة = 8 كيلو
- مساحة المبادلة = 16 جيجابايت
- تعطيل AMM (إدارة الذاكرة التلقائية)
- تعطيل الصفحات الضخمة الشفافة
اعدادات اخرى
#vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ نواة صغيرة 31457280
kernel.shmmn 4096
✓ kernel.sem = 250 32000
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓ vm.swappiness = 10
✓ vm.min_free_kbytes = 524288 # لا تقم بتعيين هذا إذا كنت تستخدم Linux x86
vm.vfs_cache_pressure = 200
✓ vm.nr_hugepages = 57000
# السادس /etc/security/limits.conf
✓ الشبكة الناعمة nproc 2047
✓ الشبكة الصلبة nproc 16384
✓ شبكة لينة nofile 1024
✓ الشبكة الصلبة nofile 65536
✓ مكدس شبكي ناعم 10240
✓ شبكة صلبة مكدس 32768
✓ أوراكل سوفت nproc 2047
✓ أوراكل هارد nproc 16384
✓ أوراكل سوفت nofile 1024
✓ أوراكل هارد nofile 65536
✓ أوراكل مكدس ناعم 10240
✓ أوراكل هارد ستيك 32768
✓ مملوك ناعم 120795954
✓ بجد memlock 120795954
sqlplus "/ as sysdba"
تغيير عمليات مجموعة النظام = 2000 نطاق = spfile ؛
تغيير مجموعة النظام open_cursors = نطاق 2000 = spfile ؛
تغيير مجموعة النظام session_cached_cursors = 300 نطاق = spfile ؛
تغيير مجموعة النظام db_files = نطاق 8192 = spfile ؛
اختبار تحمل الخطأ
لأغراض العرض التوضيحي ، تم استخدام HammerDB لمحاكاة حمل عمل OLTP. تكوين HammerDB:
عدد المستودعات
256
إجمالي المعاملات لكل مستخدم
1000000000000
المستخدمون الافتراضيون
256
كانت النتيجة 2.1M TPM ، بعيدًا عن حد أداء المصفوفة ، ولكنه "سقف" لتكوين الأجهزة الحالي للخوادم (يرجع أساسًا إلى المعالجات) وعددها. لا يزال الغرض من هذا الاختبار هو إظهار التسامح مع الخطأ للحل ككل ، وليس لتحقيق أقصى قدر من الأداء. لذلك ، سنبني ببساطة على هذا الرقم.
اختبار لفشل إحدى العقد
فقد المضيفون بعضًا من المسارات المؤدية إلى التخزين ، واستمروا في العمل من خلال بقية المسارات مع العقدة الثانية. انخفض الأداء لبضع ثوانٍ بسبب إعادة بناء المسار ثم عاد إلى طبيعته. لم يكن هناك انقطاع في الخدمة.
اختبار فشل الخزانة مع جميع المعدات
في هذه الحالة ، انخفض الأداء أيضًا لبضع ثوانٍ بسبب إعادة بناء المسارات ، ثم عاد إلى نصف القيمة الأصلية. تم تخفيض النتيجة إلى النصف مقارنة بالنسخة الأصلية بسبب استبعاد خادم تطبيق واحد من العمل. كما لم يكن هناك انقطاع في الخدمة.
إذا كانت هناك حاجة إلى تنفيذ حل التعافي من الكوارث متعدد الرفوف المتسامح مع Oracle بتكلفة معقولة وبجهود قليلة في النشر / الإدارة ، فعندئذ يعمل Oracle RAC والبنية معًا سيكون أحد أفضل الخيارات. بدلاً من Oracle RAC ، يمكن أن يكون هناك أي برنامج آخر يوفر التجميع ، مثل نظم إدارة قواعد البيانات (DBMS) أو أنظمة المحاكاة الافتراضية ، على سبيل المثال. سيبقى مبدأ بناء الحل كما هو. والنتيجة النهائية هي صفر لـ RTO و RPO.
المصدر: www.habr.com