ساخت یک راه حل مقاوم در برابر خطا بر اساس معماری Oracle RAC و AccelStor Shared-Nothing

تعداد قابل توجهی از برنامه های کاربردی سازمانی و سیستم های مجازی سازی مکانیسم های خاص خود را برای ساخت راه حل های مقاوم در برابر خطا دارند. به طور خاص، Oracle RAC (Oracle Real Application Cluster) مجموعه‌ای از دو یا چند سرور پایگاه داده Oracle است که با هم کار می‌کنند تا بار را متعادل کنند و تحمل خطا را در سطح سرور/برنامه ارائه کنند. برای کار در این حالت به یک فضای ذخیره سازی مشترک نیاز دارید که معمولاً یک سیستم ذخیره سازی است.

همانطور که قبلاً در یکی از موارد خود بحث کردیم مقالات، خود سیستم ذخیره سازی، علیرغم وجود اجزای تکراری (از جمله کنترل کننده ها)، هنوز نقاط خرابی دارد - عمدتاً به صورت یک مجموعه واحد از داده ها. بنابراین، برای ایجاد یک راه حل Oracle با نیازهای افزایش قابلیت اطمینان، طرح "N Server - One Storage System" باید پیچیده باشد.

البته ابتدا باید تصمیم بگیریم که در برابر چه خطراتی بیمه کنیم. در این مقاله، ما حفاظت در برابر تهدیداتی مانند "شهاب سنگ وارد شده" را در نظر نخواهیم گرفت. بنابراین ساختن یک راه حل بازیابی فاجعه پراکنده جغرافیایی موضوع یکی از مقالات زیر باقی خواهد ماند. در اینجا ما به راه حل موسوم به Cross-Rack Disaster Recovery نگاه می کنیم، زمانی که حفاظت در سطح کابینت سرور ساخته شده است. خود کابینت ها می توانند در یک اتاق یا در اتاق های مختلف قرار گیرند، اما معمولاً در یک ساختمان قرار دارند.

این کابینت ها باید شامل کل مجموعه تجهیزات و نرم افزار لازم باشد که بدون در نظر گرفتن وضعیت "همسایه" امکان عملکرد پایگاه داده های Oracle را فراهم می کند. به عبارت دیگر، با استفاده از راه حل بازیابی فاجعه Cross-Rack، خطرات خرابی را حذف می کنیم:

• سرورهای برنامه اوراکل
• سیستم های ذخیره سازی
• سیستم های سوئیچینگ
• خرابی کامل تمام تجهیزات داخل کابینت:
  • امتناع قدرت
  • خرابی سیستم خنک کننده
  • عوامل بیرونی (انسان، طبیعت و ...)

تکراری شدن سرورهای Oracle بر اصل عملیات Oracle RAC دلالت دارد و از طریق یک برنامه کاربردی پیاده سازی می شود. تکراری بودن امکانات سوئیچینگ نیز مشکلی ندارد. اما با تکرار سیستم ذخیره سازی، همه چیز به این سادگی نیست.

ساده ترین گزینه تکرار داده ها از سیستم ذخیره سازی اصلی به سیستم پشتیبان است. سنکرون یا ناهمزمان بسته به قابلیت های سیستم ذخیره سازی. با تکرار ناهمزمان، بلافاصله این سوال در مورد اطمینان از سازگاری داده ها در رابطه با اوراکل مطرح می شود. اما حتی در صورت وجود یکپارچگی نرم افزاری با برنامه، در هر صورت، در صورت خرابی در سیستم ذخیره سازی اصلی، مداخله دستی مدیران برای تغییر خوشه به ذخیره سازی پشتیبان مورد نیاز خواهد بود.

یک گزینه پیچیده تر، «مجازی ساز»های ذخیره سازی نرم افزار و/یا سخت افزار است که مشکلات سازگاری و مداخله دستی را از بین می برد. اما پیچیدگی استقرار و مدیریت بعدی، و همچنین هزینه بسیار نامناسب چنین راه حل هایی، بسیاری را می ترساند.

راهکار AccelStor NeoSapphire™ All Flash Array برای سناریوهایی مانند بازیابی فاجعه Cross-Rack عالی است. H710 با استفاده از معماری Shared-Nothing. این مدل یک سیستم ذخیره سازی دو گره است که از فناوری اختصاصی FlexiRemap® برای کار با درایوهای فلش استفاده می کند. با تشکر از FlexiRemap® NeoSapphire™ H710 قادر به ارائه عملکرد تا 600K IOPS@4K نوشتن تصادفی و 1M+ IOPS@4K خواندن تصادفی است که در هنگام استفاده از سیستم‌های ذخیره‌سازی مبتنی بر RAID کلاسیک دست نیافتنی است.

اما ویژگی اصلی NeoSapphire™ H710 اجرای دو گره در قالب کیس های مجزا است که هر کدام کپی مخصوص به خود را از داده ها دارند. همگام سازی گره ها از طریق رابط خارجی InfiniBand انجام می شود. به لطف این معماری، امکان توزیع گره ها در مکان های مختلف در فاصله تا 100 متر وجود دارد و در نتیجه یک راه حل بازیابی فاجعه Cross-Rack ارائه می شود. هر دو گره کاملاً همزمان عمل می کنند. از طرف میزبان، H710 شبیه یک سیستم ذخیره سازی معمولی با کنترل دوگانه به نظر می رسد. بنابراین، نیازی به انجام هیچ گونه گزینه نرم افزاری یا سخت افزاری اضافی یا تنظیمات پیچیده ای نیست.

اگر تمام راه حل های بازیابی فاجعه Cross-Rack را که در بالا توضیح داده شد مقایسه کنیم، گزینه AccelStor به طور قابل توجهی از بقیه متمایز است:

معماری AccelStor NeoSapphire™ Shared Nothing
سیستم ذخیره سازی "مجازی ساز" نرم افزار یا سخت افزار
راه حل مبتنی بر تکرار

در دسترس بودن

خرابی سرور
بدون وقفه
بدون وقفه
بدون وقفه

خرابی سوئیچ
بدون وقفه
بدون وقفه
بدون وقفه

خرابی سیستم ذخیره سازی
بدون وقفه
بدون وقفه
مدت از کار افتادگی

شکست کامل کابینه
بدون وقفه
بدون وقفه
مدت از کار افتادگی

هزینه و پیچیدگی

هزینه راه حل
کم*
زیاد
زیاد

پیچیدگی استقرار
پایین
زیاد
زیاد

*AccelStor NeoSapphire™ هنوز یک آرایه All Flash است که طبق تعریف "3 کوپک" هزینه ندارد، به خصوص که ظرفیت ذخیره آن دو برابر است. با این حال، هنگام مقایسه هزینه نهایی یک راه حل مبتنی بر آن با موارد مشابه سایر فروشندگان، می توان هزینه را کم در نظر گرفت.

توپولوژی برای اتصال سرورهای برنامه و همه گره های آرایه فلش به شکل زیر خواهد بود:

هنگام برنامه ریزی توپولوژی، همچنین به شدت توصیه می شود که سوئیچ های مدیریتی و سرورها را به هم متصل کنید.

در اینجا و بیشتر در مورد اتصال از طریق کانال فیبر صحبت خواهیم کرد. اگر از iSCSI استفاده می کنید، همه چیز یکسان خواهد بود، برای انواع سوئیچ های استفاده شده و تنظیمات آرایه کمی متفاوت تنظیم می شود.

کارهای مقدماتی روی آرایه

تجهیزات و نرم افزارهای مورد استفاده

مشخصات سرور و سوییچ

اجزاء
شرح

سرورهای 11g پایگاه داده اوراکل
دو

سیستم عامل سرور
لینوکس اوراکل

نسخه پایگاه داده اوراکل
11 گرم (RAC)

پردازنده در هر سرور
دو پردازنده 16 هسته ای Intel® Xeon® E5-2667 v2 @ 3.30GHz

حافظه فیزیکی در هر سرور
128GB

شبکه FC
FC 16Gb/s با چند مسیر

FC HBA
Emulex Lpe-16002B

پورت های اختصاصی 1GbE عمومی برای مدیریت کلاستر
آداپتور اترنت اینتل RJ45

سوئیچ FC 16 گیگابیت بر ثانیه
بروکاد 6505

پورت های اختصاصی 10GbE برای همگام سازی داده ها
اینتل X520

AccelStor NeoSapphire™ تمام مشخصات آرایه فلش

اجزاء
شرح

سیستم ذخیره سازی
مدل NeoSapphire™ در دسترس بالا: H710

نسخه تصویر
4.0.1

تعداد کل درایوها
48

اندازه درایو
1.92TB

نوع درایو
SSD

پورت های هدف FC
16 درگاه 16 گیگابایتی (8 در هر گره)

پورت های مدیریتی
کابل اترنت 1GbE که از طریق سوئیچ اترنت به هاست متصل می شود

پورت ضربان قلب
کابل اترنت 1GbE بین دو گره ذخیره سازی متصل می شود

پورت همگام سازی داده ها
کابل InfiniBand 56 گیگابیت بر ثانیه

قبل از اینکه بتوانید از یک آرایه استفاده کنید، باید آن را مقداردهی اولیه کنید. به طور پیش فرض، آدرس کنترل هر دو گره یکسان است (192.168.1.1). شما باید یک به یک به آنها متصل شوید و آدرس های مدیریتی جدید (از قبل متفاوت) تنظیم کنید و همگام سازی زمان را تنظیم کنید، پس از آن پورت های مدیریت را می توان به یک شبکه متصل کرد. پس از آن، گره ها با تخصیص زیرشبکه ها برای اتصالات Interlink در یک جفت HA ترکیب می شوند.

پس از تکمیل اولیه، می توانید آرایه را از هر گره ای مدیریت کنید.

در مرحله بعد، حجم های لازم را ایجاد می کنیم و آنها را در سرورهای برنامه منتشر می کنیم.

به شدت توصیه می شود که چندین جلد برای 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

Redo01
100GB

Redo02
100GB

Redo03
100GB

Redo04
100GB

Redo05
100GB

Redo06
100GB

Redo07
100GB

Redo08
100GB

Redo09
100GB

Redo10
100GB

برخی توضیحات در مورد حالت های عملکرد آرایه و فرآیندهای رخ داده در شرایط اضطراری

مجموعه داده های هر گره دارای یک پارامتر "شماره نسخه" است. پس از مقداردهی اولیه، یکسان و برابر با 1 است. اگر به دلایلی شماره نسخه متفاوت باشد، داده ها همیشه از نسخه قدیمی تر به نسخه جوان تر همگام می شوند، پس از آن شماره نسخه جوان تر تراز می شود، i.e. این بدان معنی است که کپی ها یکسان هستند. دلایلی که ممکن است نسخه ها متفاوت باشند:

• راه اندازی مجدد برنامه ریزی شده یکی از گره ها
• تصادف در یکی از گره ها به دلیل خاموش شدن ناگهانی (منبع برق، گرمای بیش از حد و غیره).
• اتصال InfiniBand از دست رفته با عدم امکان همگام سازی
• خرابی یکی از گره ها به دلیل خرابی داده ها. در اینجا باید یک گروه HA جدید ایجاد کنید و مجموعه داده ها را همگام سازی کامل کنید.

در هر صورت، گره‌ای که آنلاین می‌ماند، شماره نسخه خود را یک‌بار افزایش می‌دهد تا پس از بازیابی اتصال با جفت، مجموعه داده‌های خود را همگام‌سازی کند.

اگر اتصال از طریق پیوند اترنت قطع شود، Heartbeat به طور موقت به InfiniBand تغییر می کند و پس از بازیابی ظرف 10 ثانیه برمی گردد.

راه اندازی هاست

برای اطمینان از تحمل خطا و بهبود عملکرد، باید پشتیبانی MPIO را برای آرایه فعال کنید. برای انجام این کار، باید خطوطی را به فایل /etc/multipath.conf اضافه کنید و سپس سرویس چند مسیری را مجددا راه اندازی کنید.

متن پنهاندستگاه ها {
دستگاه {
فروشنده "AStor"
path_grouping_policy "group_by_prio"
path_selector "queue-length 0"
path_checker "tur"
ویژگی های "0"
hardware_handler "0"
پیشین "کنست"
برگشت سریع
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names بله
detect_prio بله
rr_min_io_rq 1
no_path_retry 0
}
}

در مرحله بعد، برای اینکه ASM از طریق ASMLib با MPIO کار کند، باید فایل /etc/sysconfig/oracleasm را تغییر دهید و سپس /etc/init.d/oracleasm scandisks را اجرا کنید.

متن پنهان

# ORACLEASM_SCANORDER: الگوهای تطبیق برای سفارش اسکن دیسک
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: الگوهای منطبق برای حذف دیسک از اسکن
ORACLEASM_SCANEXCLUDE="sd"

یادداشت

اگر نمی خواهید از ASMLib استفاده کنید، می توانید از قوانین UDEV استفاده کنید که اساس ASMLib هستند.

با شروع نسخه 12.1.0.2 پایگاه داده Oracle، این گزینه برای نصب به عنوان بخشی از نرم افزار ASMFD در دسترس است.

لازم است اطمینان حاصل شود که دیسک های ایجاد شده برای Oracle ASM با اندازه بلوکی که آرایه به طور فیزیکی با آن کار می کند (4K) تراز باشد. در غیر این صورت، ممکن است مشکلات عملکردی رخ دهد. بنابراین لازم است حجم هایی با پارامترهای مناسب ایجاد شود:

parted /dev/mapper/device-name mklabel gpt mkpart اولیه 2048s 100% align-check optimal 1

توزیع پایگاه های داده در میان حجم های ایجاد شده برای پیکربندی آزمایشی ما

نام حجم ذخیره سازی
اندازه حجم
نقشه برداری حجم LUN
جزئیات دستگاه ولوم 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
هدف: شبکه: CRS و رای گیری

4MB

Grid02
1GB

Grid03
1GB

Grid04
1GB
افزونگی: عادی
نام: DGGRID2
هدف: شبکه: CRS و رای گیری

4MB

Grid05
1GB

Grid06
1GB

Redo01
100GB
افزونگی: عادی
نام: DGREDO1
هدف: انجام مجدد گزارش موضوع 1

4MB

Redo02
100GB

Redo03
100GB

Redo04
100GB

Redo05
100GB

Redo06
100GB
افزونگی: عادی
نام: DGREDO2
هدف: انجام مجدد گزارش موضوع 2

4MB

Redo07
100GB

Redo08
100GB

Redo09
100GB

Redo10
100GB

تنظیمات پایگاه داده

• اندازه بلوک = 8K
• فضای تعویض = 16 گیگابایت
• غیرفعال کردن AMM (مدیریت خودکار حافظه)
• غیرفعال کردن صفحات بزرگ شفاف

تنظیمات دیگر

# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ 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

# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ گرید سافت نوفایل 1024
✓ گرید هارد نوفایل 65536
✓ پشته نرم شبکه ای 10240
✓ پشته هارد شبکه 32768
✓ اوراکل سافت nproc 2047
✓ oracle hard nproc 16384
✓ اوراکل سافت نوفایل 1024
✓ اوراکل هارد نوفایل 65536
✓ اوراکل سافت استک 10240
✓ اوراکل هارد استک 32768
✓ مملوک نرم 120795954
✓ مملاک سخت 120795954

sqlplus "/as sysdba"
تغییر فرآیندهای مجموعه سیستم=2000 scope=spfile;
تغییر مجموعه سیستم open_cursors=2000 scope=spfile;
تغییر مجموعه سیستم session_cached_cursors=300 scope=spfile;
تغییر مجموعه سیستم db_files=8192 scope=spfile;

تست شکست

برای اهداف نمایشی، HammerDB برای شبیه سازی بار OLTP استفاده شد. پیکربندی HammerDB:

تعداد انبارها
256

کل تراکنش ها به ازای هر کاربر
1000000000000

کاربران مجازی
256

نتیجه یک TPM 2.1M بود که با محدودیت عملکرد آرایه فاصله زیادی دارد H710، اما یک "سقف" برای پیکربندی سخت افزاری فعلی سرورها (در درجه اول به دلیل پردازنده ها) و تعداد آنها است. هدف از این آزمایش هنوز نشان دادن تحمل خطا در کل راه حل است و نه دستیابی به حداکثر عملکرد. بنابراین، ما به سادگی از این رقم استفاده می کنیم.

تست خرابی یکی از گره ها

میزبان ها بخشی از مسیرهای ذخیره سازی را از دست دادند و به کار از طریق مسیرهای باقی مانده با گره دوم ادامه دادند. به دلیل بازسازی مسیرها، عملکرد برای چند ثانیه کاهش یافت و سپس به حالت عادی بازگشت. هیچ وقفه ای در سرویس دهی وجود نداشت.

تست خرابی کابینت با تمامی تجهیزات

در این حالت عملکرد نیز به دلیل تغییر ساختار مسیرها برای چند ثانیه کاهش یافت و سپس به نصف مقدار اولیه بازگشت. نتیجه به دلیل حذف یک سرور برنامه از عملکرد، از نتیجه اولیه نصف شد. در سرویس دهی هم وقفه ای ایجاد نشد.

اگر نیاز به پیاده‌سازی یک راه‌حل بازیابی فاجعه‌بار Cross-Rack مقاوم در برابر خطا برای Oracle با هزینه معقول و با تلاش کمی برای استقرار/مدیریت وجود داشته باشد، Oracle RAC و معماری با هم کار می‌کنند. AccelStor Shared-Nothing یکی از بهترین گزینه ها خواهد بود. به جای Oracle RAC، می‌تواند هر نرم‌افزار دیگری باشد که خوشه‌بندی را ارائه می‌کند، مثلاً همان DBMS یا سیستم‌های مجازی‌سازی. اصل ساخت راه حل ثابت خواهد ماند. و نتیجه برای RTO و RPO صفر است.

منبع: www.habr.com