Oracle RAC 및 AccelStor Shared-Nothing 아키텍처를 기반으로 내결함성 솔루션 구축

상당수의 엔터프라이즈 애플리케이션과 가상화 시스템에는 내결함성 솔루션을 구축하기 위한 자체 메커니즘이 있습니다. 특히, Oracle RAC(Oracle Real Application Cluster)는 서버/애플리케이션 수준에서 로드 균형을 맞추고 내결함성을 제공하기 위해 함께 작동하는 두 개 이상의 Oracle 데이터베이스 서버로 구성된 클러스터입니다. 이 모드에서 작업하려면 일반적으로 스토리지 시스템인 공유 스토리지가 필요합니다.

우리 중 하나에서 이미 논의한 것처럼 조항, 스토리지 시스템 자체에는 중복된 구성 요소(컨트롤러 포함)가 있음에도 불구하고 주로 단일 데이터 세트 형태의 오류 지점이 있습니다. 따라서 안정성 요구 사항이 증가한 Oracle 솔루션을 구축하려면 "N개 서버 - 하나의 스토리지 시스템" 방식이 복잡해야 합니다.

먼저, 우리는 어떤 위험에 대비하려고 하는지 결정해야 합니다. 이 기사에서는 "운석이 도착했습니다"와 같은 위협으로부터의 보호를 고려하지 않습니다. 따라서 지리적으로 분산된 재해 복구 솔루션을 구축하는 것은 다음 기사 중 하나의 주제로 남을 것입니다. 여기서는 서버 캐비닛 수준에서 보호가 구축되는 소위 Cross-Rack 재해 복구 솔루션을 살펴보겠습니다. 캐비닛 자체는 같은 방이나 다른 방에 있을 수 있지만 일반적으로 같은 건물 내에 있습니다.

이러한 캐비닛에는 "이웃"의 상태에 관계없이 Oracle 데이터베이스를 작동하는 데 필요한 전체 장비 및 소프트웨어 세트가 포함되어 있어야 합니다. 즉, Cross-Rack 재해복구 솔루션을 사용하여 장애 위험을 제거합니다.

• 오라클 애플리케이션 서버
• 스토리지 시스템
• 스위칭 시스템
• 캐비닛의 모든 장비가 완전히 고장났습니다.
  • 전원 거부
  • 냉각 시스템 고장
  • 외부요인(인간, 자연 등)

Oracle 서버의 이중화는 Oracle RAC의 운영 원리 자체를 의미하며 애플리케이션을 통해 구현됩니다. 스위칭 설비의 중복도 문제가 되지 않습니다. 그러나 스토리지 시스템이 중복되면 모든 것이 그렇게 간단하지 않습니다.

가장 간단한 옵션은 기본 스토리지 시스템에서 백업 시스템으로 데이터를 복제하는 것입니다. 스토리지 시스템의 기능에 따라 동기식 또는 비동기식입니다. 비동기 복제를 사용하면 Oracle과 관련하여 데이터 일관성을 보장하는 문제가 즉시 발생합니다. 그러나 애플리케이션과 소프트웨어가 통합되어 있더라도 메인 스토리지 시스템에 장애가 발생하는 경우 클러스터를 백업 스토리지로 전환하려면 관리자의 수동 개입이 필요합니다.

더 복잡한 옵션은 일관성 문제와 수동 개입을 제거하는 소프트웨어 및/또는 하드웨어 스토리지 "가상화 프로그램"입니다. 그러나 배포 및 후속 관리의 복잡성과 이러한 솔루션의 매우 부적절한 비용으로 인해 많은 사람들이 겁을 먹습니다.

AccelStor NeoSapphire™ 올플래시 어레이 솔루션은 랙 간 재해 복구와 같은 시나리오에 적합합니다. H710 Shared-Nothing 아키텍처를 사용합니다. 이 모델은 독점 FlexiRemap® 기술을 사용하여 플래시 드라이브와 함께 작동하는 XNUMX노드 스토리지 시스템입니다. 덕분에 FlexiRemap® NeoSapphire™ H710은 최대 600K IOPS@4K 무작위 쓰기 및 1M+ IOPS@4K 무작위 읽기 성능을 제공할 수 있는데, 이는 기존 RAID 기반 스토리지 시스템을 사용할 때 달성할 수 없는 성능입니다.

그러나 NeoSapphire™ H710의 주요 특징은 각각 자체 데이터 복사본을 가지고 있는 별도의 케이스 형태로 두 개의 노드를 실행한다는 것입니다. 노드 동기화는 외부 InfiniBand 인터페이스를 통해 수행됩니다. 이러한 아키텍처 덕분에 최대 100m 거리의 ​​다양한 위치에 노드를 분산시킬 수 있어 Cross-Rack 재해복구 솔루션을 제공할 수 있습니다. 두 노드 모두 완전히 동기식으로 작동합니다. 호스트 측면에서 H710은 일반적인 듀얼 컨트롤러 스토리지 시스템처럼 보입니다. 따라서 추가 소프트웨어나 하드웨어 옵션을 수행하거나 특별히 복잡한 설정을 수행할 필요가 없습니다.

위에서 설명한 모든 Cross-Rack 재해 복구 솔루션을 비교하면 AccelStor의 옵션이 나머지 옵션보다 눈에 띄게 돋보입니다.

AccelStor NeoSapphire™ 공유 없음 아키텍처
소프트웨어 또는 하드웨어 "가상화 장치" 스토리지 시스템
복제 기반 솔루션

가용성

서버 장애
가동 불능 시간 없음
가동 불능 시간 없음
가동 불능 시간 없음

스위치 고장
가동 불능 시간 없음
가동 불능 시간 없음
가동 불능 시간 없음

스토리지 시스템 장애
가동 불능 시간 없음
가동 불능 시간 없음
중단 시간

캐비닛 전체 오류
가동 불능 시간 없음
가동 불능 시간 없음
중단 시간

비용과 복잡성

솔루션 비용
낮은*
높은
높은

배포 복잡성
낮은
높은
높은

*AccelStor NeoSapphire™는 여전히 올플래시 어레이이며, 특히 예비 용량이 두 배이기 때문에 정의상 "3코펙"의 비용이 들지 않습니다. 그러나 이를 기반으로 한 솔루션의 최종 비용을 다른 공급업체의 유사한 솔루션과 비교할 때 비용이 낮은 것으로 간주될 수 있습니다.

애플리케이션 서버와 올플래시 어레이 노드를 연결하기 위한 토폴로지는 다음과 같습니다.

토폴로지를 계획할 때 관리 스위치를 복제하고 서버를 상호 연결하는 것도 적극 권장됩니다.

여기서는 Fibre Channel을 통한 연결에 대해 설명하겠습니다. iSCSI를 사용하는 경우 모든 것이 동일하며 사용되는 스위치 유형과 약간 다른 어레이 설정에 따라 조정됩니다.

어레이 준비 작업

사용된 장비 및 소프트웨어

서버 및 스위치 사양

구성 요소
기술

오라클 데이터베이스 11g 서버
두

서버 운영 체제
오라클 리눅스

오라클 데이터베이스 버전
11g(RAC)

서버당 프로세서
16코어 Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz XNUMX개

서버당 물리적 ​​메모리
128GB

FC 네트워크
다중 경로 기능을 갖춘 16Gb/s FC

FC HBA
에뮬렉스 Lpe-16002B

클러스터 관리를 위한 전용 공용 1GbE 포트
인텔 이더넷 어댑터 RJ45

16Gb/s FC 스위치
브로케이드 6505

데이터 동기화를 위한 전용 개인 10GbE 포트
Intel X520

AccelStor NeoSapphire™ 올플래시 어레이 사양

구성 요소
기술

저장 시스템
NeoSapphire™ 고가용성 모델: H710

이미지 버전
4.0.1

총 드라이브 수
48

드라이브 크기
1.92TB

드라이브 유형
SSD

FC 대상 포트
16개의 16Gb 포트(노드당 8개)

관리 포트
이더넷 스위치를 통해 호스트에 연결되는 1GbE 이더넷 케이블

하트비트 포트
두 스토리지 노드 사이를 연결하는 1GbE 이더넷 케이블

데이터 동기화 포트
56Gb/s InfiniBand 케이블

배열을 사용하려면 먼저 초기화해야 합니다. 기본적으로 두 노드의 제어 주소는 동일합니다(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

그리드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 그룹을 생성하고 데이터 세트의 동기화를 완료해야 합니다.

어떤 경우든 온라인 상태를 유지하는 노드는 쌍과의 연결이 복원된 후 데이터 세트를 동기화하기 위해 버전 번호를 XNUMX씩 증가시킵니다.

이더넷 링크를 통한 연결이 끊어지면 Heartbeat는 일시적으로 InfiniBand로 전환되었다가 복원되면 10초 이내에 다시 돌아옵니다.

호스트 설정

내결함성을 보장하고 성능을 향상하려면 어레이에 대해 MPIO 지원을 활성화해야 합니다. 이렇게 하려면 /etc/multipath.conf 파일에 행을 추가한 다음 멀티패스 서비스를 다시 시작해야 합니다.

숨겨진 텍스트장치 {
장치 {
벤더 "AStor"
path_grouping_policy "group_by_prio"
path_selector "대기열 길이 0"
path_checker "tur"
특징 "0"
hardware_handler "0"
프리오 "const"
즉각적인 장애 복구
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friend_names 예
detector_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을 사용하지 않으려면 ASMLib의 기반이 되는 UDEV 규칙을 사용할 수 있습니다.

Oracle Database 버전 12.1.0.2부터 이 옵션을 ASMFD 소프트웨어의 일부로 설치할 수 있습니다.

Oracle ASM용으로 생성된 디스크가 어레이가 물리적으로 작동하는 블록 크기(4K)에 맞춰 정렬되어 있는지 확인하는 것이 중요합니다. 그렇지 않으면 성능 문제가 발생할 수 있습니다. 따라서 적절한 매개변수를 사용하여 볼륨을 생성해야 합니다.

parted /dev/mapper/device-name mklabel gpt mkpart 기본 2048s 100% 정렬 확인 최적 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

그리드01
1GB
중복성: 보통
이름: DGGRID1
목적:그리드: CRS 및 투표

4MB

그리드02
1GB

그리드03
1GB

그리드04
1GB
중복성: 보통
이름: DGGRID2
목적:그리드: CRS 및 투표

4MB

그리드05
1GB

그리드06
1GB

다시 실행01
100GB
중복성: 보통
이름: DGREDO1
목적: 스레드 1의 Redo 로그

4MB

다시 실행02
100GB

다시 실행03
100GB

다시 실행04
100GB

다시 실행05
100GB

다시 실행06
100GB
중복성: 보통
이름: DGREDO2
목적: 스레드 2의 Redo 로그

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_압력=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ 그리드 소프트 nproc 2047
✓ 그리드 하드 nproc 16384
✓ 그리드 소프트 노파일 1024
✓ 그리드 하드 노파일 65536
✓ 그리드 소프트 스택 10240
✓ 그리드 하드 스택 32768
✓ 오라클 소프트 nproc 2047
✓ 오라클 하드 nproc 16384
✓ 오라클 소프트 노파일 1024
✓ 오라클 하드 노파일 65536
✓ 오라클 소프트 스택 10240
✓ 오라클 하드스택 32768
✓ 소프트 멤락 120795954
✓ 하드 메모리락 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이 탄생했습니다. H710, 그러나 서버의 현재 하드웨어 구성(주로 프로세서로 인해)과 그 수에 대한 "천장"입니다. 이 테스트의 목적은 솔루션 전체의 내결함성을 입증하는 것이지 최대 성능을 달성하는 것은 아닙니다. 그러므로 우리는 이 수치를 토대로 간단히 작성하겠습니다.

노드 중 하나의 오류 테스트

호스트는 스토리지 경로의 일부를 잃어버렸고, 두 번째 노드를 사용하여 나머지 경로를 계속해서 작업했습니다. 경로 재구축으로 인해 몇 초 동안 성능이 저하되었다가 다시 정상으로 돌아왔습니다. 서비스 중단은 없었습니다.

모든 장비에 대한 캐비닛 고장 테스트

이 경우에도 경로 재구성으로 인해 몇 초 동안 성능이 저하되었다가 원래 값의 절반으로 돌아왔습니다. 애플리케이션 서버 XNUMX개를 운영에서 제외하여 결과가 당초 대비 절반으로 줄었습니다. 서비스 중단도 없었습니다.

합리적인 비용과 약간의 배포/관리 노력으로 Oracle을 위한 내결함성 Cross-Rack 재해 복구 솔루션을 구현해야 하는 경우 Oracle RAC와 아키텍처가 함께 작동합니다. AccelStor 공유 없음 최고의 선택 중 하나가 될 것입니다. Oracle RAC 대신 클러스터링을 제공하는 다른 소프트웨어, 예를 들어 동일한 DBMS 또는 가상화 시스템이 있을 수 있습니다. 솔루션 구성 원칙은 동일하게 유지됩니다. 그리고 RTO와 RPO의 결론은 XNUMX입니다.

출처 : habr.com