Значителен брой корпоративни приложения и системи за виртуализация имат свои собствени механизми за изграждане на устойчиви на грешки решения. По-конкретно, Oracle RAC (Oracle Real Application Cluster) е клъстер от два или повече сървъра на база данни на Oracle, работещи заедно, за да балансират натоварването и да осигурят толерантност към грешки на ниво сървър/приложение. За да работите в този режим, имате нужда от споделено хранилище, което обикновено е система за съхранение.
Както вече обсъдихме в един от нашите , самата система за съхранение, въпреки наличието на дублирани компоненти (включително контролери), все още има точки на повреда - главно под формата на единичен набор от данни. Следователно, за да се изгради решение на Oracle с повишени изисквания за надеждност, схемата „N сървъра - една система за съхранение“ трябва да бъде сложна.
Първо, разбира се, трябва да решим срещу какви рискове се опитваме да се застраховаме. В тази статия няма да разглеждаме защита срещу заплахи като „пристигна метеорит“. Така че изграждането на географски разпръснато решение за възстановяване след бедствие ще остане тема за една от следващите статии. Тук ще разгледаме т. нар. Cross-Rack disaster recovery решение, когато защитата е изградена на ниво сървърни шкафове. Самите шкафове могат да бъдат разположени в една и съща стая или в различни, но обикновено в рамките на една и съща сграда.
Тези шкафове трябва да съдържат целия необходим набор от оборудване и софтуер, който ще позволи работата на базите данни на Oracle, независимо от състоянието на „съседа“. С други думи, използвайки решението за възстановяване след авария Cross-Rack, ние елиминираме рисковете от повреда:
- Сървъри за приложения на Oracle
- Системи за съхранение
- Превключващи системи
- Пълен отказ на цялото оборудване в шкафа:
- Отказ на захранване
- Неизправност на охладителната система
- Външни фактори (човек, природа и др.)
Дублирането на Oracle сървъри предполага самия принцип на работа на Oracle RAC и се реализира чрез приложение. Дублирането на комутационни съоръжения също не е проблем. Но с дублирането на системата за съхранение всичко не е толкова просто.
Най-простият вариант е репликация на данни от основната система за съхранение към резервната. Синхронен или асинхронен, в зависимост от възможностите на системата за съхранение. При асинхронната репликация веднага възниква въпросът за осигуряване на съгласуваност на данните по отношение на Oracle. Но дори и да има софтуерна интеграция с приложението, във всеки случай, ако има повреда в основната система за съхранение, ще е необходима ръчна намеса от администратори, за да превключите клъстера към резервно хранилище.
По-сложна опция са софтуерни и/или хардуерни „виртуализатори“ за съхранение, които ще премахнат проблемите с последователността и ръчната намеса. Но сложността на внедряването и последващото администриране, както и много неприличната цена на такива решения, обезкуражават мнозина.
Решението AccelStor NeoSapphire™ All Flash array е идеално за сценарии като възстановяване след катастрофа на Cross-Rack използвайки Shared-Nothing архитектура. Този модел е система за съхранение с два възела, която използва патентована технология FlexiRemap® за работа с флаш устройства. Благодарение на NeoSapphire™ H710 е в състояние да осигури производителност до 600K IOPS@4K случайно записване и 1M+ IOPS@4K произволно четене, което е недостижимо при използване на класически RAID-базирани системи за съхранение.
Но основната характеристика на NeoSapphire™ H710 е изпълнението на два възела под формата на отделни случаи, всеки от които има собствено копие на данните. Синхронизирането на възлите се осъществява чрез външния интерфейс InfiniBand. Благодарение на тази архитектура е възможно да се разпределят възли на различни места на разстояние до 100 м, като по този начин се осигурява решение за възстановяване след авария на Cross-Rack. И двата възела работят напълно синхронно. От страната на хоста H710 изглежда като обикновена система за съхранение с двоен контролер. Поради това не е необходимо да се извършват допълнителни софтуерни или хардуерни опции или особено сложни настройки.
Ако сравним всички решения за възстановяване след авария на Cross-Rack, описани по-горе, тогава опцията от AccelStor се откроява забележимо от останалите:
AccelStor NeoSapphire™ Shared Nothing Architecture
Софтуерна или хардуерна система за съхранение „виртуализатор“.
Решение, базирано на репликация
наличност
Сървърна грешка
Без престой
Без престой
Без престой
Неизправност на превключвателя
Без престой
Без престой
Без престой
Неизправност на системата за съхранение
Без престой
Без престой
Престой
Цялата повреда на шкафа
Без престой
Без престой
Престой
Цена и сложност
Цена на решението
ниско*
Високо
Високо
Сложност на внедряване
ниско
Високо
Високо
*AccelStor NeoSapphire™ все още е All Flash масив, който по дефиниция не струва „3 копейки“, особено след като има двоен резервен капацитет. Въпреки това, когато се сравнява крайната цена на базирано на него решение с подобни от други доставчици, цената може да се счита за ниска.
Топологията за свързване на сървъри на приложения и всички възли на Flash масив ще изглежда така:
При планирането на топологията е силно препоръчително също така да се дублират превключватели за управление и свързване на сървъри.
Тук и по-нататък ще говорим за свързване чрез Fibre Channel. Ако използвате iSCSI, всичко ще бъде същото, коригирано за типовете използвани суичове и малко по-различни настройки на масива.
Подготвителна работа по масива
Използвано оборудване и софтуер
Спецификации на сървъра и комутатора
Елементи
описание
Сървъри на Oracle Database 11g
две
Сървърна операционна система
Oracle Linux
Версия на базата данни на Oracle
11g (RAC)
Процесори на сървър
Два 16 ядра Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Физическа памет на сървър
128GB
FC мрежа
16Gb/s FC с мултипатинг
FC HBA
Emulex Lpe-16002B
Специализирани публични 1GbE портове за управление на клъстери
Intel Ethernet адаптер RJ45
16Gb/s FC превключвател
Брокат 6505
Специализирани частни 10GbE портове за синхронизиране на данни
Intel X520
Спецификация на AccelStor NeoSapphire™ All Flash Array
Елементи
описание
Система за съхранение
Модел с висока наличност NeoSapphire™: H710
Версия на изображението
4.0.1
Общ брой дискове
48
Размер на диска
1.92TB
Тип на устройството
SSD
FC целеви портове
16x 16Gb портове (8 на възел)
Портове за управление
1GbE Ethernet кабел, свързващ се с хостове чрез Ethernet комутатор
Порт за сърдечен ритъм
1GbE Ethernet кабел, свързващ два възела за съхранение
Порт за синхронизиране на данни
56Gb/s InfiniBand кабел
Преди да можете да използвате масив, трябва да го инициализирате. По подразбиране контролният адрес на двата възела е един и същ (192.168.1.1). Трябва да се свържете с тях един по един и да зададете нови (вече различни) адреси за управление и да настроите времева синхронизация, след което портовете за управление могат да бъдат свързани към една мрежа. След това възлите се комбинират в HA двойка чрез присвояване на подмрежи за Interlink връзки.
След като инициализацията приключи, можете да управлявате масива от всеки възел.
След това създаваме необходимите томове и ги публикуваме на сървъри на приложения.
Силно препоръчително е да създадете множество томове за Oracle ASM, тъй като това ще увеличи броя на целите за сървърите, което в крайна сметка ще подобри цялостната производителност (повече за опашките в друг ).
Тестова конфигурация
Име на том за съхранение
Обем размер
Данни01
200GB
Данни02
200GB
Данни03
200GB
Данни04
200GB
Данни05
200GB
Данни06
200GB
Данни07
200GB
Данни08
200GB
Данни09
200GB
Данни10
200GB
Решетка01
1GB
Решетка02
1GB
Решетка03
1GB
Решетка04
1GB
Решетка05
1GB
Решетка06
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 и след това да рестартирате услугата multipath
Скрит текстустройства {
устройство {
доставчик "AStor"
path_grouping_policy "group_by_prio"
path_selector "дължина на опашка 0"
path_checker "tur"
функции "0"
hardware_handler "0"
преди "конст"
failback незабавно
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). В противен случай може да възникнат проблеми с производителността. Следователно е необходимо да се създадат обеми със съответните параметри:
parted /dev/mapper/device-name 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
Решетка01
1GB
Резервиране: Нормално
Име: DGGRID1
Цел: Решетка: CRS и гласуване
4MB
Решетка02
1GB
Решетка03
1GB
Решетка04
1GB
Резервиране: Нормално
Име: DGGRID2
Цел: Решетка: CRS и гласуване
4MB
Решетка05
1GB
Решетка06
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
- Суап пространство = 16GB
- Деактивиране на 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
✓ мека мрежа nproc 2047
✓ твърда мрежа nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ мек стек на мрежата 10240
✓ мрежов твърд стек 32768
✓ Oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ Oracle мек стек 10240
✓ твърд стек на oracle 32768
✓ soft memlock 120795954
✓ твърд memlock 120795954
sqlplus “/като 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
Резултатът беше 2.1M TPM, което е далеч от лимита на производителността на масива , но е „таван“ за текущата хардуерна конфигурация на сървърите (предимно поради процесорите) и техния брой. Целта на този тест все още е да демонстрира отказоустойчивостта на решението като цяло, а не да постигне максимална производителност. Затова просто ще градим върху тази цифра.
Тествайте за повреда на един от възлите
Хостовете загубиха част от пътищата към хранилището, като продължиха да работят през останалите с втория възел. Производителността падна за няколко секунди поради възстановяването на пътищата и след това се върна към нормалното. Нямаше прекъсване на обслужването.
Тест за повреда на шкафа с цялото оборудване
В този случай производителността също спадна за няколко секунди поради преструктурирането на пътищата и след това се върна на половината от първоначалната стойност. Резултатът е наполовина от първоначалния поради изключване от работа на един сървър за приложения. Нямаше и прекъсване на обслужването.
Ако има нужда от внедряване на устойчиво на грешки Cross-Rack решение за възстановяване след авария за Oracle на разумна цена и с малко усилия за внедряване/администриране, тогава Oracle RAC и архитектурата работят заедно ще бъде един от най-добрите варианти. Вместо Oracle RAC може да има всеки друг софтуер, който осигурява клъстериране, същите СУБД или системи за виртуализация, например. Принципът на конструиране на решението ще остане същият. И долната линия е нула за RTO и RPO.
Източник: www.habr.com