Значителен број на 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 враќање од катастрофи користејќи ја архитектурата Shared-Nothing. Овој модел е систем за складирање со два јазли кој користи сопствена технологија FlexiRemap® за работа со флеш-уреди. Благодарение на NeoSapphire™ H710 е способен да дава перформанси до 600K IOPS@4K случајно запишување и 1M+ IOPS@4K случајно читање, што е недостижно кога се користат класични системи за складирање базирани на RAID.
Но, главната карактеристика на NeoSapphire™ H710 е извршувањето на два јазли во форма на посебни случаи, од кои секој има своја копија од податоците. Синхронизацијата на јазлите се врши преку надворешниот интерфејс InfiniBand. Благодарение на оваа архитектура, можно е да се дистрибуираат јазли на различни локации на оддалеченост до 100 m, со што се обезбедува решение за враќање од катастрофи Cross-Rack. Двата јазли работат целосно синхроно. Од страната на домаќинот, H710 изгледа како обичен систем за складирање со двоен контролер. Затоа, нема потреба да вршите дополнителни софтверски или хардверски опции или особено сложени поставки.
Ако ги споредиме сите решенија за враќање од катастрофи Cross-Rack опишани погоре, тогаш опцијата од AccelStor значително се издвојува од останатите:
Архитектура на споделено ништо на AccelStor NeoSapphire™
Систем за складирање на софтвер или хардвер „виртуелизатор“.
Решение засновано на репликација
Достапност
Неуспех на серверот
Без застој
Без застој
Без застој
Неуспех на прекинувачот
Без застој
Без застој
Без застој
Неуспех на системот за складирање
Без застој
Без застој
Престој
Целосен дефект на кабинетот
Без застој
Без застој
Престој
Цена и сложеност
Цена на решение
Ниско*
Висок
Висок
Сложеност на распоредувањето
Ниско
Висок
Висок
*AccelStor NeoSapphire™ сè уште е низа за сите Flash, која по дефиниција не чини „3 копејки“, особено затоа што има двојна резерва на капацитет. Меѓутоа, кога се споредуваат крајните трошоци на решението засновано на него со слични од други продавачи, цената може да се смета за ниска.
Топологијата за поврзување на апликативни сервери и сите јазли со низа Flash ќе изгледа вака:
При планирање на топологијата, исто така многу се препорачува да се дуплираат управувачки прекинувачи и меѓусебно поврзување на серверите.
Овде и понатаму ќе зборуваме за поврзување преку Fiber Channel. Ако користите iSCSI, сè ќе биде исто, приспособено за типовите на користени прекинувачи и малку поинакви поставки на низата.
Подготвителна работа на низата
Користена опрема и софтвер
Спецификации на сервер и прекинувач
Компоненти
Опис
Сервери на Oracle Database 11g
Две
Оперативен систем на серверот
Оракл Линукс
Верзија на базата на податоци на Oracle
11 g (RAC)
Процесори по сервер
Два 16 јадра Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Физичка меморија по сервер
128GB
ФК мрежа
16Gb/s FC со повеќепати
ФК ХБА
Emulex Lpe-16002B
Посебни јавни порти од 1GbE за управување со кластери
Интел етернет адаптер RJ45
16Gb/s FC прекинувач
Брокада 6505
Посебни приватни порти од 10 GbE за синхронизација на податоци
Intel X520
AccelStor NeoSapphire™ Спецификација за сите блиц низи
Компоненти
Опис
Систем за складирање
Модел со висока достапност на NeoSapphire™: H710
Верзија на слика
4.0.1
Вкупен број на погони
48
Големина на погонот
1.92TB
Тип на возење
SSD
Целни пристаништа на FC
16x 16Gb порти (8 по јазол)
Управувачки пристаништа
Етернет кабелот од 1GbE се поврзува со домаќините преку етернет прекинувач
Пристаниште за отчукување на срцето
Етернет кабелот од 1GbE што се поврзува помеѓу два јазли за складирање
Порта за синхронизација на податоци
56Gb/s InfiniBand кабел
Пред да можете да користите низа, мора да ја иницијализирате. Стандардно, контролната адреса на двата јазли е иста (192.168.1.1). Треба да се поврзете со нив еден по еден и да поставите нови (веќе различни) адреси за управување и да поставите синхронизација на времето, по што портите за управување може да се поврзат на една мрежа. Потоа, јазлите се комбинираат во пар 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
Повтори01
100GB
Повтори02
100GB
Повтори03
100GB
Повтори04
100GB
Повтори05
100GB
Повтори06
100GB
Повтори07
100GB
Повтори08
100GB
Повтори09
100GB
Повтори10
100GB
Некои објаснувања за режимите на работа на низата и процесите што се случуваат во итни ситуации
Збирот на податоци на секој јазол има параметар „број на верзијата“. По првичната иницијализација, тој е ист и еднаков на 1. Ако поради некоја причина бројот на верзијата е различен, тогаш податоците секогаш се синхронизираат од постарата верзија со помладата, по што се порамнува бројот на помладата верзија, т.е. тоа значи дека копиите се идентични. Причини зошто верзиите може да бидат различни:
- Закажано рестартирање на еден од јазлите
- Несреќа на еден од јазлите поради ненадејно исклучување (напојување, прегревање итн.).
- Изгубена врска InfiniBand со неможност за синхронизација
- Несреќа на еден од јазлите поради оштетување на податоците. Овде ќе треба да креирате нова HA група и целосна синхронизација на множеството податоци.
Во секој случај, јазолот што останува онлајн го зголемува бројот на својата верзија за еден со цел да го синхронизира својот сет на податоци откако ќе се обнови врската со парот.
Ако врската преку етернет врската се изгуби, Heartbeat привремено се префрла на InfiniBand и се враќа во рок од 10 секунди кога ќе се врати.
Поставување домаќини
За да обезбедите толеранција на грешки и да ги подобрите перформансите, мора да овозможите MPIO поддршка за низата. За да го направите ова, треба да додадете линии во датотеката /etc/multipath.conf, а потоа да ја рестартирате услугата за повеќе патеки
Скриен текстуреди {
уред {
продавач "AStor"
path_grouping_policy "group_by_prio"
path_selector "должина на редица 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 да работи со MPIO преку ASMLib, треба да ја смените датотеката /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 Database, опцијата е достапна за инсталација како дел од софтверот ASMFD.
Неопходно е да се осигурате дека дисковите креирани за Oracle ASM се усогласени со големината на блокот со која физички работи низата (4K). Во спротивно, може да се појават проблеми со перформансите. Затоа, неопходно е да се создадат томови со соодветни параметри:
разделени /dev/mapper/device-name mklabel gpt mkpart основно 2048s 100% align-check оптимално 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
Повтори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
Поставки на базата на податоци
- Големина на блок = 8K
- Заменете го просторот = 16 GB
- Оневозможи AMM (автоматско управување со меморијата)
- Оневозможи Транспарентни огромни страници
Други поставки
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ кернел.shmmax 103079215104
✓ кернел.shmall 31457280
✓ кернел.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
✓ решетка мека нофиле 1024
✓ тврд нофил на мрежа 65536
✓ мек стек на решетка 10240
✓ тврд стек на решетка 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ Oracle hard nofile 65536
✓ Oracle soft stack 10240
✓ Oracle hard stack 32768
✓ мек мемблок 120795954
✓ тврд мемблок 120795954
sqlplus „/as sysdba“
измени системски сет процеси=2000 опсег=spfile;
менувајте системско множество open_cursors=2000 scope=spfile;
промена на системскиот сет session_cached_cursors=300 опсег=spfile;
менувајте системско множество db_files=8192 опсег=spfile;
Тест за неуспех
За демонстративни цели, HammerDB се користеше за емулирање на оптоварување OLTP. Конфигурација на HammerDB:
Број на магацини
256
Вкупно трансакции по корисник
1000000000000
Виртуелни корисници
256
Резултатот беше 2.1 M TPM, што е далеку од ограничувањето на перформансите на низата , но е „плафон“ за моменталната хардверска конфигурација на серверите (пред се поради процесорите) и нивниот број. Целта на овој тест е сепак да се демонстрира толеранцијата на грешки на решението како целина, а не да се постигнат максимални перформанси. Затоа, ние едноставно ќе се надоврземе на оваа бројка.
Тест за неуспех на еден од јазлите
Домаќините изгубија дел од патеките до складиштето, продолжувајќи да работат преку останатите со вториот јазол. Перформансите паднаа за неколку секунди поради обновувањето на патеките, а потоа се вратија во нормала. Немаше прекин во сервисот.
Тест за дефект на кабинетот со целата опрема
Во овој случај, перформансите исто така паднаа за неколку секунди поради реструктуирањето на патеките, а потоа се вратија на половина од првобитната вредност. Резултатот беше преполовен од првичниот поради исклучувањето на еден апликациски сервер од работа. Немаше прекин ниту во сервисот.
Ако има потреба да се имплементира решение за обновување катастрофи Cross-Rack кое е толерантно за грешки за Oracle по разумна цена и со мал напор за распоредување/администрација, тогаш Oracle RAC и архитектурата работат заедно ќе биде една од најдобрите опции. Наместо Oracle RAC, може да има кој било друг софтвер кој обезбедува кластерирање, исти DBMS или системи за виртуелизација, на пример. Принципот на конструирање на решението ќе остане ист. И крајната линија е нула за RTO и RPO.
Извор: www.habr.com