Oracle RAC жана AccelStor Shared-Nothing архитектурасына негизделген каталарга чыдамдуу чечимди куруу

Көптөгөн Enterprise тиркемелери жана виртуалдаштыруу системалары каталарга чыдамдуу чечимдерди түзүү үчүн өз механизмдерине ээ. Тактап айтканда, Oracle RAC (Oracle Real Application Cluster) – бул жүктү тең салмактоо жана сервер/тиркеме деңгээлинде каталарга чыдамкайлыкты камсыз кылуу үчүн чогуу иштеген эки же андан көп Oracle маалымат базасы серверлеринин кластери. Бул режимде иштөө үчүн сизге жалпы сактагыч керек, ал адатта сактоо тутуму болуп саналат.

Биз буга чейин биздин биринде талкуулагандай макалалар, сактоо тутумунун өзү, кайталанган компоненттердин (анын ичинде контроллерлордун) бар экендигине карабастан, дагы эле иштебей калуу учурлары бар - негизинен, маалыматтардын бирдиктүү топтому түрүндө. Ошондуктан, ишенимдүүлүгүн жогорулатуу талаптары менен Oracle чечимин куруу үчүн, "N сервер - бир сактоо системасы" схемасы татаал болушу керек.

Биринчиден, албетте, биз кандай тобокелдиктерден камсыздандырууга аракет кылып жатканыбызды чечишибиз керек. Бул макалада биз "метеорит келди" сыяктуу коркунучтардан коргонууну карап чыкпайбыз. Ошентип, географиялык жактан чачыранды болгон кырсыкты калыбына келтирүү чечимин куруу кийинки макалалардын бири үчүн тема бойдон кала берет. Бул жерде биз Cross-Rack деп аталган кырсыкты калыбына келтирүү чечимин карап чыгабыз, качан коргоо сервердик шкафтардын деңгээлинде курулган. Кабинеттердин өздөрү бир бөлмөдө же ар башка болушу мүмкүн, бирок көбүнчө бир имараттын ичинде.

Бул шкафтар "коңшусунун" абалына карабастан Oracle маалымат базаларынын иштешине мүмкүндүк берүүчү жабдуулардын жана программалык камсыздоонун бардык керектүү комплексин камтышы керек. Башка сөз менен айтканда, Cross-Rack кырсыкты калыбына келтирүү чечимин колдонуу менен, биз ийгиликсиз болуу тобокелдиктерин жок кылабыз:

• Oracle колдонмо серверлери
• сактоо системалары
• Коммутациялык системалар
• Кабинеттеги бардык жабдуулардын толук бузулушу:
  • Бийликтен баш тартуу
  • Муздатуу системасы иштебей калды
  • Тышкы факторлор (адам, жаратылыш, ж.

Oracle серверлеринин кайталанышы Oracle RACтин иштөө принцибин билдирет жана тиркеме аркылуу ишке ашырылат. Коммутациялык каражаттардын кайталанышы да көйгөй жаратпайт. Бирок сактоо системасынын кайталанышы менен, баары жөнөкөй эмес.

Эң жөнөкөй вариант - маалыматтын негизги тутумунан резервдик тутумга көчүрүү. Сактоо тутумунун мүмкүнчүлүктөрүнө жараша синхрондуу же асинхрондуу. Асинхрондук репликация менен, дароо Oracleга карата маалыматтардын ырааттуулугун камсыз кылуу маселеси туулат. Бирок, тиркеме менен программалык камсыздоонун интеграциясы бар болсо да, кандай болгон күндө да, негизги сактоо тутумунда иштебей калган учурда, кластерди резервдик сактоого которуу үчүн администраторлордун кол менен кийлигишүүсү талап кылынат.

Бир кыйла татаал вариант программалык камсыздоо жана/же аппараттык сактоочу “виртуализаторлор” болуп саналат, алар ырааттуулук көйгөйлөрүн жана кол менен кийлигишүүнү жок кылат. Бирок жайгаштыруунун жана андан кийинки башкаруунун татаалдыгы, ошондой эле мындай чечимдердин өтө уятсыз баасы көптөрдү коркутат.

AccelStor NeoSapphire™ All Flash массивинин чечими 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™ Архитектура эч нерсе бөлүшпөгөн
Программалык камсыздоо же аппараттык "виртуализатор" сактоо системасы
Репликацияга негизделген чечим

болушу

Сервердин катасы
Тыныгуу жок
Тыныгуу жок
Тыныгуу жок

Которуу иштебей калды
Тыныгуу жок
Тыныгуу жок
Тыныгуу жок

Сактоо тутумунун катасы
Тыныгуу жок
Тыныгуу жок
даун

Кабинеттин бүтүндөй иштебей калышы
Тыныгуу жок
Тыныгуу жок
даун

Наркы жана татаалдыгы

Чечимдин баасы
Төмөн*
Высокая
Высокая

Жайгаштыруунун татаалдыгы
төмөн
Высокая
Высокая

* AccelStor NeoSapphire™ дагы эле All Flash массиви болуп саналат, анын аныктамасы боюнча "3 копейк" кымбаттабайт, айрыкча анын эки эселенген кубаттуулук резерви бар. Бирок, ага негизделген чечимдин акыркы баасын башка сатуучулардын окшоштору менен салыштырганда, наркы төмөн деп эсептесе болот.

Колдонмо серверлерин жана Бардык Flash массив түйүндөрүн туташтыруу үчүн топология төмөнкүдөй болот:

Топологияны пландаштырууда башкаруу которгучтарын кайталоо жана серверлерди өз ара туташтыруу сунушталат.

Бул жерде жана андан ары Fiber Channel аркылуу туташуу жөнүндө сүйлөшөбүз. Эгер сиз iSCSI колдонсоңуз, бардыгы бирдей болот, колдонулган которгучтардын түрлөрүнө жана бир аз башкача массив орнотууларына ылайыкташтырылган.

Массив боюнча даярдык иштери

Колдонулган жабдуулар жана программалык камсыздоо

Сервер жана Switch спецификациялары

компоненттери
баяндоо

Oracle Database 11g серверлери
эки

Server операциялык системасы
oracle Linux

Oracle маалымат базасынын версиясы
11г (RAC)

Процессорлор ар серверге
Эки 16 өзөктүү Intel® Xeon® CPU E5-2667 v2 @ 3.30 ГГц

Серверге физикалык эс
128GB

FC тармагы
Көп жол менен 16 Гб/с FC

FC HBA
Emulex Lpe-16002B

Кластерди башкаруу үчүн атайын коомдук 1GbE порттору
Intel Ethernet адаптери RJ45

16Gb/s FC которуу
Бука 6505

Маалыматтарды синхрондоштуруу үчүн атайын жеке 10GbE порттору
Intel X520

AccelStor NeoSapphire™ All Flash Array Specification

компоненттери
баяндоо

Сактоо системасы
NeoSapphire™ жогорку жеткиликтүүлүк модели: H710

Сүрөт версиясы
4.0.1

Дисктердин жалпы саны
48

Drive өлчөмү
1.92TB

Drive түрү
SSD

FC максаттуу порттору
16x 16Gb порттору (ар бир түйүн үчүн 8)

Башкаруу порттору
1GbE Ethernet кабели Ethernet которуштуруусу аркылуу хостторго туташат

Жүрөк согуу порту
1GbE Ethernet кабели эки сактоо түйүнүнүн ортосунда туташтырылган

Маалыматтарды синхрондоштуруу порту
56Gb/s InfiniBand кабели

Массивди колдонуудан мурун, аны инициализациялашыңыз керек. Демейки боюнча, эки түйүндүн башкаруу дареги бирдей (192.168.1.1). Сиз аларга бир-бирден туташып, жаңы (андан эле башка) башкаруу даректерин коюп, убакыт синхрондоштурууну жөндөшүңүз керек, андан кийин Башкаруу порттору бир тармакка туташса болот. Андан кийин, түйүндөр Interlink байланыштары үчүн субторлорду дайындоо аркылуу HA жупуна бириктирилет.

Инициализация аяктагандан кийин массивди каалаган түйүндөн башкара аласыз.

Андан кийин, биз керектүү томдорду түзүп, аларды тиркеме серверлерине жарыялайбыз.

Oracle ASM үчүн бир нече томдорду түзүү сунушталат, анткени бул серверлер үчүн максаттардын санын көбөйтөт, ал акырында жалпы иштөөнү жакшыртат (башкасында кезектер жөнүндө көбүрөөк маалымат). макала).

Сыноо конфигурациясы

Сактагыч көлөмүнүн аталышы
Көлөмдүн көлөмү

Маалымат01
200GB

Маалымат02
200GB

Маалымат03
200GB

Маалымат04
200GB

Маалымат05
200GB

Маалымат06
200GB

Маалымат07
200GB

Маалымат08
200GB

Маалымат09
200GB

Маалымат10
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ге барабар. Эгерде кандайдыр бир себептерден улам версиянын номери башка болсо, анда маалыматтар дайыма эски версиядан кичүү версияга синхрондолот, андан кийин кичүү версиянын саны тегизделет, б.а. бул көчүрмөлөр окшош экенин билдирет. Версиялардын ар кандай болушунун себептери:

• Түйүндөрдүн бирин пландаштырылган кайра жүктөө
• Түйүндөрдүн биринде капыстан өчүрүү (энергия менен камсыздоо, ысып кетүү ж.б.у.с.) болгон авария.
• InfiniBand байланышы үзүлүп, синхрондоштуруу мүмкүн эмес
• Маалыматтын бузулушунан улам түйүндөрдүн биринде бузулуу. Бул жерде сиз жаңы HA тобун түзүп, маалымат топтомун толук синхрондоштурууңуз керек.

Кандай болгон күндө да, онлайн бойдон калган түйүн жуп менен байланыш калыбына келтирилгенден кийин, анын маалымат топтомун синхрондоштуруу үчүн версия номерин бир көбөйтөт.

Ethernet шилтемеси аркылуу байланыш үзүлсө, Heartbeat убактылуу InfiniBandге которулат жана ал калыбына келгенде 10 секунданын ичинде кайра кайтып келет.

Хосттарды орнотуу

Мүчүлүштүктөрдү толеранттуулукту камсыз кылуу жана иштөөсүн жакшыртуу үчүн массив үчүн MPIO колдоосун иштетишиңиз керек. Бул үчүн, сиз /etc/multipath.conf файлына саптарды кошуп, андан кийин көп жолдуу кызматты кайра иштетишиңиз керек.

Жашырылган тексттүзмөктөр {
аппарат {
сатуучу "AStor"
path_grouping_policy "group_by_prio"
path_selector "кезектин узундугу 0"
path_checker "tur"
өзгөчөлүктөрү "0"
hardware_handler "0"
prio "const"
токтоосуз
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 скандисктерин иштетишиңиз керек.

Жашырылган текст

# ORACLEASM_SCANORDER: Дискти сканерлөө үчүн үлгүлөрдү дал келтирүү
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: Дисктерди сканерлөөдөн чыгаруу үчүн үлгүлөрдү дал келтирүү
ORACLEASM_SCANEXCLUDE="sd"

пикир

Эгерде сиз ASMLibди колдонгуңуз келбесе, анда ASMLib үчүн негиз болгон UDEV эрежелерин колдоно аласыз.

Oracle маалыматтар базасынын 12.1.0.2 версиясынан баштап, ASMFD программасынын бир бөлүгү катары орнотуу үчүн опция жеткиликтүү.

Oracle ASM үчүн түзүлгөн дисктер массив физикалык жактан (4K) иштеген блоктун өлчөмүнө шайкеш келишин камсыздоо зарыл. Болбосо, аткаруу көйгөйлөрү пайда болушу мүмкүн. Ошондуктан, тиешелүү параметрлери менен көлөмүн түзүү зарыл:

parted /dev/mapper/түзмөктүн аты mklabel gpt mkpart негизги 2048s 100% тегиздөө-текшерүү оптималдуу 1

Сыноо конфигурациябыз үчүн түзүлгөн томдор боюнча маалымат базаларын бөлүштүрүү

Сактагыч көлөмүнүн аталышы
Көлөмдүн көлөмү
Көлөмдүн LUN картасы
ASM Көлөмү түзмөгүнүн чоо-жайы
Бөлүштүрүү бирдигинин өлчөмү

Маалымат01
200GB
Бардык сактоо көлөмүн сактоо тутумунун бардык маалымат портторуна салыштырыңыз
Артыкчылык: Кадимки
Аты-жөнү: DGDATA
Максаты: Маалымат файлдары

4MB

Маалымат02
200GB

Маалымат03
200GB

Маалымат04
200GB

Маалымат05
200GB

Маалымат06
200GB

Маалымат07
200GB

Маалымат08
200GB

Маалымат09
200GB

Маалымат10
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.shmal 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
✓ тор жумшак nproc 2047
✓ тор катуу nproc 16384
✓ тор жумшак nofile 1024
✓ тор катуу nofile 65536
✓ тор жумшак стек 10240
✓ тор катуу стек 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ oracle жумшак стек 10240
✓ Oracle катуу стек 32768
✓ жумшак memlock 120795954
✓ hard memlock 120795954

sqlplus "/ as sysdba"
система топтому процесстерин өзгөртүү = 2000 масштаб = spfile;
система топтомун өзгөртүү open_cursors=2000 scope=spfile;
система топтомун өзгөртүү session_cached_cursors=300 scope=spfile;
система топтомун өзгөртүү db_files=8192 scope=spfile;

Ийгиликсиз сыноо

Демонстрациялоо максатында, HammerDB OLTP жүгүн эмуляциялоо үчүн колдонулган. HammerDB конфигурациясы:

Кампалардын саны
256

Бир колдонуучуга жалпы транзакциялар
1000000000000

Виртуалдык колдонуучулар
256

Натыйжада массивдин аткаруу чегинен алыс болгон 2.1M TPM болду H710, бирок серверлердин учурдагы аппараттык конфигурациясынын (биринчи кезекте процессорлордун эсебинен) жана алардын саны үчүн "шып" болуп саналат. Бул тесттин максаты дагы эле бүтүндөй чечимдин катачылыкка чыдамдуулугун көрсөтүү жана максималдуу аткарууга жетишүү эмес. Ошондуктан, биз жөн гана бул көрсөткүчкө таянабыз.

Түйүндөрдүн биринин иштебей калышын текшерүү

Хосттар сактагычка баруучу жолдордун бир бөлүгүн жоготуп, калгандары менен экинчи түйүн менен иштөөнү улантышты. Аткаруу жолдору кайра курулуп жаткандыктан бир нече секундага төмөндөп, андан кийин нормалдуу абалга келди. Кызматта үзгүлтүккө учураган жок.

Бардык жабдуулар менен кабинеттин иштебей калышын текшерүү

Бул учурда, жолдордун реструктуризацияланышына байланыштуу аткаруу да бир нече секундага төмөндөп, андан кийин баштапкы маанинин жарымына кайтып келди. Бир тиркеме серверинин иштөөсүнөн четтетилгендиктен натыйжа баштапкысынан эки эсеге кыскарды. Кызматта да үзгүлтүккө учураган жок.

Эгерде Oracle үчүн каталарга чыдамдуу Cross-Rack кырсыктан калыбына келтирүү чечимин акылга сыярлык баада жана аз жайылтуу/администрациялоо аракети менен ишке ашыруу зарыл болсо, анда Oracle RAC жана архитектура бирге иштешет. AccelStor Shared - Эч нерсе мыкты варианттарынын бири болуп калат. Oracle RACдин ордуна, мисалы, кластерлөө, ошол эле DBMS же виртуалдаштыруу системаларын камсыз кылган башка программа болушу мүмкүн. Чечимди куруу принциби ошол эле бойдон кала берет. Ал эми төмөнкү линия RTO жана RPO үчүн нөлгө барабар.

Source: www.habr.com