SIOS LifeKeeper를 사용하여 AWS에서 HANA 3노드 HSR 클러스터로 고가용성 구축

SIOS LifeKeeper를 사용하여 AWS에서 HANA 3노드 HSR 클러스터로 고가용성 구축

소개: 데이터베이스에서 HA 및 DR을 보장하는 방법

AWS에서 고가용성 SAP HANA 환경을 구축하는 것은 많은 기업에게 중요한 작업입니다. 이 가이드에서는 다음을 사용하여 3노드 HANA 시스템 복제(HSR) 클러스터를 설정하는 방법에 대한 자세한 연습을 제공합니다.SIOS 라이프키퍼AWS에서는 데이터베이스 보장회복력그리고고가용성.

전제조건

• EC2 인스턴스를 배포할 수 있는 AWS 계정입니다.
• SIOS LifeKeeper 소프트웨어
• SIOS LifeKeeper 평가판 또는 영구 라이센스
• SAP HANA 소프트웨어
• AWS 서비스 및 SAP HANA에 대한 지식.

1단계: AWS 환경 준비

EC2 인스턴스 배포

AWS에 3개의 EC2 인스턴스를 배포합니다. 이러한 인스턴스는 HANA 클러스터의 기본, 보조 및 3차 노드 역할을 합니다. SAP HANA 및 SIOS LifeKeeper에 대한 하드웨어 및 소프트웨어 요구 사항을 충족하는지 확인하세요. 인스턴스를 구축할 때 SAP HANA 크기 조정 지침을 따라야 합니다.

네트워크 구성

노드 간 통신을 허용하고 필요한 서비스에 대한 액세스를 활성화하도록 VPC, 서브넷 및 보안 그룹을 구성합니다.

다른 지역에서 HANA 노드를 구성할 때 Linux Route53 애플리케이션 복구 키트 또는 ARK용 SIOS LifeKeeper를 사용하여 DNS 이름을 보호할 수 있습니다. 다음은 AWS의 3노드 HANA 데이터베이스에 대한 아키텍처입니다.

스토리지를 설정할 때 /usr/sap, /hana/data, /hana/log 및 /hana/shared에 대해 별도의 EBS 볼륨을 사용하십시오.

각 지역마다 하나씩 2개의 VPC가 있습니다. 서버가 서로 통신할 수 있도록 VPC 간에 피어링을 설정하고 라우팅 테이블에 경로를 추가해야 합니다. 또한 서버 간 트래픽을 허용하도록 보안 그룹을 수정해야 합니다.

마지막으로 두 VPC를 모두 포함하는 호스팅 영역을 생성하고 활성 HANA 노드와 통신하는 데 사용할 도메인 및 호스트 이름에 대한 레코드를 추가해야 합니다.

2단계: SAP HANA 설치 및 구성

각 노드에 설치

각 EC2 인스턴스에 SAP HANA를 설치합니다. 호환성 문제를 방지하려면 버전이 모든 노드에서 일관되게 유지되는지 확인하세요. 이것은 지금까지 가장 어려운 과정입니다.

설치 설정을 결정하는 것부터 시작하십시오. 내 경우에는 다음을 사용하고 있습니다.

시드: D11

• HANA 인스턴스 번호: 11
• Route53의 HANA db fqdn: saphana.sapdemo
• Node1 호스트 이름: sapdemohana1
• Node2 호스트 이름:sapdemohana2
• Node3 호스트 이름:sapdemohana3
• 인스턴스 유형: r5.4xlarge

로컬 인스턴스 스토리지:

• 30GB / (루트 볼륨)
• 15GB /usr/sap
• 60GB /하나/공유*
• 200GB /하나/데이터
• 200GB /하나/로그

*이 설치의 경우 이는 이러한 HANA 데이터베이스 서버 간에 공유되지 않는 스토리지입니다. 공유 저장소를 사용하려고 하면 hdblcm이 이미 존재하는 SID와 인스턴스에 대한 오류로 인해 설치를 방해하므로 동일한 서버를 생성할 수 없습니다.

마치 독립형 시스템인 것처럼 각 노드에 HANA 서버 소프트웨어를 독립적으로 설치합니다. 필요한 모든 라이브러리가 설치되어 있는지 확인하세요. RHEL 8의 경우 SAP Note 2772999에 있습니다. Compact-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm을 설치한 후 심볼릭 링크를 생성해야 합니다. 다음을 실행하여: ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6

• yum install xorg-x11-server-Xorg xorg-x11-xauth -y #LifeKeeper GUI용
• 냠 nfs-utils 설치

파티션을 생성하고 스토리지를 포맷한 후 연결하세요. 스왑 파일을 만듭니다.

모든 호스트에서 RSA 키를 생성한 다음 .ssh/authorized_keys 파일에 공개 키를 추가하여 Hana 노드 간의 루트 SSH 로그인을 허용합니다. 이렇게 하면 설치가 훨씬 쉬워집니다.

HANA 설치 미디어 볼륨을 탑재합니다.

• 냠 localinstall compat-sap-c++-10-10.2.1-11.el7_9.x86_64.rpm
• 냠 localinstall compat-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm
• mkdir /usr/sap/lib
• ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6
• 냠 설치 compat-sap-c++-10 libatomic -y

올바른 하나 설치 미디어 디렉터리에서 hdblcm을 실행합니다. 모든 노드에 HANA를 성공적으로 설치했다면 다음 단계를 진행할 준비가 된 것입니다.

시스템 복제 설정

HSR을 활성화하기 전에 백업을 수행해야 합니다.

• su – <SID>adm [즉. su -d11adm]
• hdbsql -i <인스턴스 번호>adm -u system -p <비밀번호> [즉. hdbsql -i 11 -u 시스템 -p “password123”]
• FILE(‘/usr/sap/<SID>/HDB<인스턴스 번호>’)를 사용하여 데이터 백업 [ie. FILE(‘/usr/sap/D11/HDB11’)을 사용하여 데이터 백업

모든 노드에서 위의 백업 프로세스를 반복합니다.

각 노드에서 HANA 시스템 복제를 구성합니다.

아직 실행되고 있지 않은 경우 기본 HANA 시스템에서 HDB 인스턴스를 시작합니다. sapcontrol -nr <instance number> -function StartSystem HDB [예: sapcontrol -nr 11 -function StartSystem HDB]

기본 사이트에서 HSR을 시작합니다: hdbnsutil -sr_enable –name=<기본 사이트 이름> [ie. hdbnsutil -sr_enable –name=sapdemohana1

보조 HANA 시스템에서 HDB 인스턴스를 중지합니다. sapcontrol -nr <인스턴스 번호> -function StopSystem HDB [ie. sapcontrol -nr 11 -기능 StopSystem HDB]

추가 HANA 시스템에서 KEY 및 DAT 파일을 백업하고 기본 KEY 및 DAT 파일을 필요한 위치에 복사합니다.

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>. DAT.BAK [즉. mv /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT.BAK]

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>. KEY.BAK [즉. mv /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY.BAK]

• scp root@<기본 노드>:/usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/ data/SSFS_<SID>.DAT [즉. scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT]

• scp root@<기본 노드>:/usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/ 키/SSFS_<SID>.KEY [예: scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY]

키 및 dat 파일의 소유자가 <SID>adm sapsys인지 확인하세요.

• [root@sapdemohana2 ~]# ls -l /usr/sap/D11/SYS/global/security/rsecssfs/data/
• 총 12개
• -rw-r–r– 1 d11adm sapsys 2960 1월 3일 22:19 SSFS_D11.DAT
• -rw-r–r– 1 d11adm sapsys 2960 1월 3일 22:15 SSFS_D11.DAT.BAK

기본 HANA 시스템에 추가 HANA 시스템을 등록하려면 관리자 권한으로 수행해야 합니다.

• hdbnsutil -sr_register –name=<보조 HSR의 이름> –remoteHost=<SAP HANA 시스템의 기본 호스트 이름> –remoteInstance=<원격 인스턴스 번호> –OperationMode=<delta_datashipping | 로그 재생 | logreplay_readaccess> –replicationMode=<동기화 | 동기화 | 비동기>

[즉. hdbnsutil -sr_register –name=sapdemohana2 –remoteHost=sapdemohana1 –remoteInstance=11 –operationMode=logreplay –replicationMode=sync]

모든 시스템에서 HSR 상태를 확인하고 관리 사용자로 다음 명령을 실행합니다. d11adm@sapdemohana4:/usr/sap/D11/HDB11>hdbnsutil -sr_state

모든 시스템이 온라인 상태가 되면 다음 단계로 넘어갈 수 있습니다.

3단계: SIOS LifeKeeper 설치

AWS CLI 설치

AWS CLI를 설치하고 다음 권한이 있는 키로 구성합니다.

라우팅 테이블(백엔드) 구성:

• ec2:경로 테이블 설명
• ec2:경로 바꾸기
• ec2:DescribeNetworkInterface속성
• ec2:ModifyNetworkInterface속성
• 탄력적 IP(프런트엔드) 구성:
• ec2:주소 설명
• ec2:어소시에이트주소
• ec2:DisassociateAddress

라이프키퍼 설치

각 노드에 SIOS LifeKeeper를 설치합니다. 여기에는 설치 스크립트를 실행하고 필요한 단계를 안내하는 설치 마법사를 따르는 것이 포함됩니다. 이번 설치에서는 네트워킹인 Route53 ARK와 데이터베이스인 SAP HANA ARK를 감시 기능과 함께 사용하고 있습니다.

/etc/selinux/config 파일을 편집하고 selinux를 비활성화합니다:

또한 호스트 이름을 변경하고 /etc/hosts 파일을 편집했습니다. 마지막으로 /etc/default/LifeKeeper 파일을 편집하고 PATH에 /usr/local/bin을 추가합니다.

NOBCASTPING=1 변경:

또한 QUORUM_LOSS_ACTION을 osu로 변경했습니다.

Xwindows가 작동하는지 확인하세요. .bashrc에서 cp 별칭을 제거하고 .bash_profile에 /opt/LifeKeeper/bin 및 /usr/local/bin을 추가하고 ec2-users .Xauthority 파일을 루트 및 <SID>adm 홈 디렉터리에 복사하여 Xwindows가 작동합니다:

루트 비밀번호를 변경하고 재부팅합니다. LifeKeeper GUI를 시작하기 전. HSR이 모든 노드에서 온라인 상태이고 모든 노드가 등록되어 있는지 확인하십시오.

구성

LifeKeeper GUI: lkGUIapp을 실행하고 루트 사용자와 비밀번호로 로그인합니다.

클러스터의 추가 노드에 로그인하려면 연결 버튼을 클릭하세요.

모든 노드에 로그인한 후 Create Comm Path 버튼을 클릭합니다.

로컬 서버를 요청하면 다음을 누르고 Shift 키를 누른 채 모든 노드를 선택합니다.

기본값 수락을 누르고 완료되면 완료를 누르십시오. Create Comm path 버튼을 다시 클릭하고 이번에는 두 번째 노드로 변경합니다.

다음을 누르고 세 번째 노드를 선택합니다.

기본값 수락 버튼을 누를 수 있을 때까지 다음 버튼을 누르세요. 완전한 히트가 완료되면. 이제 리소스 계층 생성 버튼을 클릭하세요.

IP 키트를 선택하고 다음을 누르십시오.

IP 리소스 페이지가 나올 때까지 다음을 누르세요. 여기에 0.0.0.0을 입력하고 다음을 누르십시오.

만들기 버튼이 나올 때까지 다음을 누르세요. 만들기 버튼을 누르세요:

완료되면 다음을 누르십시오. 두 번째 노드를 표시하는 대상 서버에서 기본값 수락을 누르십시오.

완료되면 다음 서버를 누르십시오.

세 번째 노드가 표시된 상태에서 Accept Defaults를 누르고 완료되면 Finish를 누릅니다.

히트 완료:

이제 우리는 fqdn을 활성 노드 IP 주소로 확인하기 위해 dns 항목을 변경하는 Route53 리소스를 추가할 수 있는 IP 리소스를 갖게 되었습니다. 이 경우 saphana.sapdemo는 sapdemohana1(172.31.0.25)의 IP 주소로 확인됩니다. 프로세스를 시작하려면 리소스 계층 생성 버튼을 누르세요.

Route53을 선택하고 다음을 누르십시오.

도메인 이름에 도달할 때까지 다음을 계속 누르십시오. 활성 호스팅 영역 이름이 미리 채워져 있어야 합니다. 다음을 누르세요.

모든 것이 HANA 데이터베이스에 연결하는 데 사용할 호스트 이름을 입력하고 다음을 누르십시오.

생성 버튼이 나올 때까지 다음을 누르고 생성 버튼을 클릭하세요. 완료되면 다음을 누르세요.

사전 확장 마법사에서 기본값 수락을 누르십시오.

완료되면 다음 서버를 누르십시오.

대상 서버에는 세 번째 노드가 표시됩니다. 기본값 수락을 누르십시오.

완료되면 마침을 누르세요. 그런 다음 완료를 누르십시오. 그런 다음 트리를 확장할 수 있습니다. 두 번째 노드에 대한 터미널 세션을 열고 HANA 데이터베이스에 대한 fqdn을 ping합니다. ping -c3 saphana.sapdemo]

sapdemohana3 아래의 상단 대기를 마우스 오른쪽 버튼으로 클릭하고 In Service를 선택합니다.

다음 화면에서 In Service를 누르고 완료되면 Done을 ​​누릅니다.

터미널 창으로 이동하여 ping 테스트를 반복합니다.

이제 호스트 이름이 sapdemohana3으로 확인되는 것을 볼 수 있습니다. 다음 단계로 넘어가기 전에 sapdemohana1을 다시 서비스에 투입하세요.

4단계: SAP HANA를 SIOS LifeKeeper와 통합

리소스 계층 생성

LifeKeeper GUI를 사용하여 각 노드에서 SAP HANA에 대한 리소스 계층 구조를 만듭니다. 이 설정은 장애 조치 및 복구 프로세스를 관리하는 데 중요합니다. HSR이 node1에서 활성화되어 있고 추가 노드가 등록되어 있는지 확인하십시오.

리소스 생성 버튼을 클릭합니다:

SAP HANA 복구 키트를 선택하고 IP 주소 화면이 나타날 때까지 다음을 누르세요.

아무것도 선택하지 않고 다음을 누르십시오.

Create 화면이 나타날 때까지 다음을 누르고 Create를 누릅니다.

생성 후 다음을 누르고 node2에 대한 기본값 수락:

다시 node2가 완료되면 Next Server를 누르고 기본값 수락을 누르십시오.

완료되면 마침을 누르고 완료를 누릅니다.

Hana Hierarchy를 마우스 오른쪽 버튼으로 클릭하고 종속성 만들기를 선택합니다.

하위 리소스 태그의 경우 풀다운에서 Route53 리소스를 선택하고 다음을 누르십시오.

종속성 생성을 클릭합니다.

완료를 클릭하세요. 그런 다음 보기 확장 트리를 선택합니다.

모든 것이 녹색이면 테스트할 준비가 된 것입니다.

5단계: 테스트 및 검증

장애 조치/전환 테스트

철저한 장애 조치 테스트를 수행하여 기본 노드 오류가 발생할 경우 시스템이 보조 또는 3차 노드로 올바르게 전환되는지 확인합니다. 이 테스트에는 네트워크 오류, 하드웨어 문제, 소프트웨어 충돌과 같은 시나리오가 포함되어야 합니다.

우리가 수행할 첫 번째 테스트는 유지 관리 활동을 수행하거나 예정된 중단이 발생한 경우에 사용되는 전환입니다. 두 번째 노드를 마우스 오른쪽 버튼으로 클릭하고 In Service – Takeover with Handshake…를 선택합니다.

인계 수행을 누르십시오.

이 테스트에서는 사용자 가동 중지 시간을 최소화하면서 두 번째 노드로 전환합니다. 두 번째 노드가 실행 중이면 완료를 누르십시오.

잠시 후 node1이 다시 대기 상태(In Sync)로 돌아옵니다.

이제 장애 조치 테스트를 수행할 수 있습니다. 노드 2에 대한 터미널을 열고 echo c > /proc/sysrq-trigger를 입력하여 시스템 충돌을 시뮬레이션합니다. 우선순위가 가장 높은 노드 1이 인계받는 것을 볼 수 있습니다.

결국 모든 것이 정상으로 돌아갈 것입니다.

테스트할 수 있는 추가 오류 시나리오 유형이 많이 있습니다. 테스트를 시작하기 전에 대기 노드가 동기화되어 있는지 확인하세요.

데이터 동기화 확인

모든 노드에서 데이터가 올바르게 복제되는지 확인합니다. HSR 설정의 무결성을 위해서는 노드 전체에서 일관된 데이터가 중요합니다.

성능 모니터링

SAP HANA 인스턴스 및 LifeKeeper 설정의 성능을 정기적으로 모니터링합니다. 잠재적인 문제를 나타낼 수 있는 이상 현상이나 문제가 있는지 확인하세요. /var/log/lifekeeper.log 파일을 확인하여 모든 것이 예상대로 작동하는지 확인하세요. 네트워크 성능에 따라 하트비트 타이머와 누락된 하트비트 수를 조정해야 할 수도 있습니다. 이는 /etc/default/LifeKeeper 파일에서 구성할 수 있습니다. 조정 가능 항목은 LCMHBEATTIME 및 LCMNUMHBEATS입니다. 또한 lcdstatus -q 명령을 사용하여 명령줄에서 Lifekeeper의 상태를 확인할 수도 있습니다.

결론

SIOS LifeKeeper를 사용하여 AWS에서 3노드 HANA HSR 클러스터를 설정하려면 세부적인 계획과 실행이 필요합니다. 이러한 단계를 주의 깊게 따르면 클라우드에서 강력하고 탄력적이며 가용성이 높은 SAP HANA 환경을 구축하여 중요한 데이터에 대한 액세스와 보안을 유지할 수 있습니다. Linux용 SIOS LifeKeeper를 사용하면 SAP HANA의 관리, 모니터링 및 유지 관리를 빠르고 쉽게 수행할 수 있습니다.

SIOS가 제공하는자원그리고훈련우리의 모든 제품에 대해.

다음의 허가를 받아 복제됨시오스

미국 수도 지역은 SIOS DataKeeper를 사용하여 중요한 긴급 파견 서비스를 보호합니다.

미국 수도 지역은 SIOS DataKeeper를 사용하여 중요한 긴급 파견 서비스를 보호합니다.

SIOS DataKeeper는 Azure의 SQL Server에서 중요한 CAD-EX CAD2CAD 소프트웨어를 보호합니다.

최근까지 배치 담당자는 인근 관할 구역에 있는 장치의 위치와 가용성을 추정하는 컴퓨터 지원 파견(CAD) 시스템을 사용했지만 파견을 요청하려면 전용 전화선으로 인근 기관에 전화하여 실제 장치 위치와 가용성을 확인해야 했습니다. . 이 프로세스로 인해 대응 시간이 느려지고 긴급 구조원이 파견 기관에서 제공할 수 있는 중요한 사건 세부 정보에 액세스할 수 없었습니다.

효율성을 높이기 위해 NCR 기관 리더십과 EDC(Emerging Digital Concepts)는 협력하여 DEH(데이터 교환 허브)를 만들었습니다. 이는 회원 NCR 응급 서비스 기관에 데이터 및 애플리케이션에 대한 안전한 액세스를 제공하도록 설계된 데이터 교환 및 기능적 상호 운용성 플랫폼입니다. NIEM(National Information Exchange Model)을 사용하여 시스템, 통신 및 절차의 상호 운용성을 보장했습니다.

DEH는 비상 대응에 있어서 효율적인 지역 협력의 국가 모델이 되었습니다. 전국 수도 지역에 대한 효율적인 긴급 파견 서비스 보장 SIOS DataKeeper는 Azure의 SQL Server에서 중요한 CAD-EX CAD2CAD 소프트웨어를 보호합니다.

기본 DEH 정보 교환은 CAD-to-CAD(C2C) 교환으로, 이를 통해 모든 NCR DEH 기관의 파견 담당자는 일선 리소스 위치, 리소스 가용성을 즉시 이해하고 관련 사고에 대한 최신 정보를 공유할 수 있습니다. 회원 관할권의 모든 C2C Exchange 연결 CAD 시스템.

NCR DEH C2C Exchange는 Windows Server에서 작동하는 Microsoft SQL Server 데이터베이스를 사용하며 Azure Commercial Cloud에 배포됩니다. 이러한 시스템의 중요한 특성을 고려하여 DEH는 C2C Exchange 플랫폼에 대한 고가용성 데이터 보호를 요구했습니다. 추가 복잡성 없이 장애 조치 클러스터링 데이터베이스가 포함된 기존 Windows 고가용성(HA) 환경에서는 두 개 이상의 데이터베이스 인스턴스 노드가 구성됩니다. 공유 스토리지(일반적으로 SAN)가 있는 Windows Server 장애 조치 클러스터.

데이터베이스는 HA 장애 조치 소프트웨어가 해당 작업을 모니터링하는 기본 노드에서 작동합니다. 문제가 감지되면 HA 소프트웨어는 클러스터의 대기 보조 노드에 대한 데이터베이스 작업의 장애 조치를 조정합니다. 공유 스토리지를 사용할 수 없거나 비용 효율적이지 않은 클라우드 및 기타 환경에서는 복제를 사용하여 각 클러스터 노드의 로컬 스토리지를 동기화하여 SANless 클러스터를 생성하므로 장애 조치 시 보조 노드가 계속 작동할 수 있습니다. 현재 데이터로 작동합니다.

프로젝트 초기 단계에서 NCR IT 팀은 다양한 환경에 C2C Exchange 플랫폼을 배포했습니다. 여기에는 온프레미스 Fairfax County 데이터 센터가 포함되었으며 이후에는 여러 타사, 국가 및 지역 호스팅 공급자 환경이 포함되었습니다. 이러한 환경에서 C2C Exchange 데이터베이스 배포 아키텍처는 Microsoft SQL Server Enterprise Edition 및 Always On 가용성 그룹을 사용했습니다.

프로젝트가 확장됨에 따라 NCR IT 팀은 발전된 클라우드 기술을 활용하고 C2C 플랫폼을 Azure 상업용 클라우드에 배포하도록 추진되었습니다. 클라우드는 보다 가상적인 환경에서 C2C 플랫폼을 관리하는 데 필요한 유연성과 서비스 수준을 제공했습니다.

또한 Azure 클라우드를 통해 NCR은 보다 비용 효율적이고 가용성이 높은 데이터베이스 클러스터링 솔루션을 배포하여 C2C Exchange 애플리케이션 데이터를 자신 있게 제공하는 동시에 SQL Server Enterprise Edition과 관련된 높은 라이선스 비용을 줄일 수 있었습니다.

해결책

NCR DEH C2C Exchange는 Azure Commercial Cloud에서 C2C Exchange 데이터 가용성을 보호하기 위해 SANless 클러스터를 만들기 위해 SIOS DataKeeper Cluster Edition 소프트웨어를 사용하기 시작했습니다. 이 소프트웨어는 Always On 장애 조치 클러스터링과 함께 SQL Server Standard Edition을 활용하는 2노드 활성-수동 Windows Server 장애 조치 클러스터 구성에서 실행됩니다.

SIOS DataKeeper 소프트웨어는 대역폭 효율적인 호스트 기반 블록 수준 복제를 사용하여 모든 데이터베이스 클러스터 노드에서 로컬 스토리지를 동기화합니다. 애플리케이션 가용성 문제가 감지되면 수동 개입 없이 작업이 자동으로 보조 노드로 이동됩니다. 클라우드 공급업체가 보장하는 서비스 수준은 하드웨어 작동성을 보장하지만 소프트웨어 및 네트워킹 관련 애플리케이션 다운타임 원인은 포함하지 않습니다.

결과

NCR DEH C2C Exchange는 Azure Commercial Cloud에서 SIOS DataKeeper Cluster Edition 소프트웨어를 2년 넘게 사용해 왔습니다. 상호 운용성 프로그램 참여가 증가했습니다. 초기 회원 외에도 이 프로그램에는 이제 MWAA(Metro Washington Airports Authority), 버지니아 카운티 Loudoun 및 Prince William, 메릴랜드 카운티 Montgomery 및 Prince George’s가 포함됩니다. C2C Exchange는 수천 개의 공유 장치를 관리하고 이러한 참가자 간에 매년 수십만 건의 사고에 대한 데이터를 공유합니다.

SIOS DataKeeper Cluster Edition을 사용하면 클라우드에서 고가용성 데이터베이스 클러스터를 빠르고 간단하게 구축할 수 있습니다. EDC 최고 기술 책임자이자 공동 창립자인 Greg Crider는 “우리는 Windows Server 장애 조치 클러스터 노드에 SIOS DataKeeper를 설치하고 복제를 위한 SIOS 관리 스토리지로 로컬 노드 스토리지를 구성했으며 원활하게 작동했습니다.”라고 말했습니다. “SIOS DataKeeper 클러스터링 소프트웨어의 또 다른 이점은 계획된 가동 중지 시간이나 서비스 중단 없이 필요에 따라 클러스터 노드를 전환하여 데이터베이스에서 정기적인 롤링 소프트웨어 유지 관리를 수행할 수 있다는 것입니다.”

NCR C2C Exchange에서 SIOS DataKeeper를 구현한 이후 데이터베이스 또는 노드 간 데이터 손실과 관련된 가동 중지 시간 문제가 발생하지 않았습니다. EDC 사장, CEO, 공동 창업자인 Chris Wiseman은 다음과 같이 덧붙였습니다. “예상치 못한 통제할 수 없는 네트워킹 문제가 몇 가지 있었지만 데이터베이스는 빠르게 장애 조치되었으며 C2C Exchange 운영은 장기적인 서비스 감소로 인해 최종 사용자가 영향을 받지 않고 계속되었습니다. SIOS DataKeeper 소프트웨어를 사용하면 더 비싼 SQL Server Enterprise Edition 라이선스 없이도 더 높은 수준의 데이터 보호 및 전달을 제공할 수 있습니다. 이는 우리 이해관계자들에게 지속적으로 상당한 연간 비용 절감 효과를 가져다줍니다.”

SIOS DataKeeper 보호 기능을 갖춘 NCR C2C Exchange는 DHS/SAFECOM의 비디오 링크에 나와 있습니다. 최근 은행과 아파트단지, 요양원 등에서 3건의 대형화재가 동시에 발생하면서 테스트에 들어갔다. CAD 시스템 간의 상호 운용성은 이러한 사고에 빠르고 효율적으로 대응하는 데 중요한 역할을 했습니다.

EDC는 상업적으로 이용 가능한 NG-CAD-X C2C Exchange 제품을 통해 미국 전역의 다른 시장에서 C2C Exchange 채택을 확대하고 있습니다. 기능적으로 진보된 이 C2C 서비스는 덴버시 북부 중앙 All-Hazards 지역과 플로리다 남동부 지역에서 구현되고 있습니다. NG-CAD-X는 화재 및 EMS ESF 외에도 CJIS 규정 준수 및 법 집행 채택을 위해 Azure Government Cloud에 배포된 NCR C2C Exchange와 호환되는 메시지이며 SIOS DataKeeper Cluster Edition을 모든 데이터베이스 아키텍처에 구현합니다. 위에 강조된 운영 및 비용 효율적인 이유. “전략적 파트너십은 고객에게 시장에서 최고의 기술 솔루션을 제공하는 데 중요한 역할을 합니다. SIOS DataKeeper는 우리 시스템의 필수적인 부분이며 귀중한 EDC 파트너입니다.” EDC의 부사장인 Kevin Konczal은 말했습니다.

PDF 다운로드

다음의 허가를 받아 복제됨시오스

웹 세미나: Azure에서 SAP 및 SAP S/4HANA 보호: 재해 복구 모범 사례

웹 세미나: Azure에서 SAP 및 SAP S/4HANA 보호: 재해 복구 모범 사례

오늘날의 디지털 환경에서는 비즈니스 연속성에 영향을 미칠 수 있는 잠재적인 재해로부터 보호하기 위해 SAP 및 SAP S/4HANA와 같은 중요한 비즈니스 애플리케이션을 보호하는 것이 가장 중요합니다. Azure는 클라우드 컴퓨팅의 강력한 기능을 활용하여 SAP 및 SAP S/4HANA 환경을 위한 강력한 재해 복구 솔루션을 제공합니다. 이 주문형 심포지엄 세션에서는 다음 전략을 포함하여 Azure에서 SAP 및 SAP S/4HANA 시스템을 보호하기 위한 모범 사례를 논의합니다.데이터 복제, 백업 및 복원, 고가용성 및 장애 조치. Azure 클라우드의 SAP에서 Fast Track을 담당하는 Microsoft 수석 고객 엔지니어인 Harikrishna Madathala는 재해 복구 모범 사례를 구현하여 Azure에서 SAP 및 SAP S/4HANA 배포를 보호하고 최고 수준을 보장하는 데 도움이 되는 통찰력, 실용적인 팁 및 실제 사례를 공유합니다. 중요한 비즈니스 애플리케이션에 대한 보안, 탄력성 및 가용성을 제공합니다.

다음의 허가를 받아 복제됨시오스

웹 세미나: AWS 기반 SAP의 복원력: 고가용성 및 비즈니스 연속성을 달성하기 위한 모범 사례

웹 세미나: AWS 기반 SAP의 복원력: 고가용성 및 비즈니스 연속성을 달성하기 위한 모범 사례

주문형 웨비나에 등록하세요

이 주문형 심포지엄 세션은 달성하기 위한 모범 사례에 중점을 둡니다.고가용성AWS 기반 SAP 및 SAP S/4HANA 애플리케이션에 대한 비즈니스 연속성. 클라우드 인프라에 대한 의존도가 높아짐에 따라 기업은 잠재적인 중단으로부터 중요한 데이터와 애플리케이션을 보호하기 위해 탄력적이고 안정적인 SAP 시스템을 갖추는 것이 필수적입니다.

AWS는 백업 및 복구, 복제, 장애 조치를 포함하여 AWS 기반 SAP 및 SAP S/4HANA에 대한 고가용성 및 재해 복구의 주요 구성 요소에 대한 포괄적인 개요를 제공합니다. 그리고 AWS에서 사용할 수 있는 다양한 전략과 도구를 살펴보세요. AWS에서 탄력적이고 안정적인 SAP 및 SAP S/4HANA를 생성하는 방법에 대한 통찰력을 얻으십시오.

다음의 허가를 받아 복제됨시오스

웨비나: 자동화된 멀티타겟을 통한 SAP 고가용성 및 재해 복구 극대화: 모범 사례 및 교훈

웨비나: 자동화된 멀티타겟을 통한 SAP 고가용성 및 재해 복구 극대화: 모범 사례 및 교훈

주문형 웨비나에 등록하세요

이 주문형 심포지엄 세션에서는 멀티 타겟 클러스터 아키텍처의 중요한 역할을 살펴봅니다.고가용성SAP S/4 HANA 및 SAP HANA 환경에 대한 재해 복구. 실제 사례와 실용적인 통찰력을 통해 위험 감소, 탄력성 향상 및 비즈니스 연속성 보장 측면에서 다중 대상 클러스터 아키텍처의 이점을 이해하십시오. SAP 고가용성 및 재해 복구를 극대화하는 데 있어 다중 대상 클러스터 아키텍처의 중요한 역할에 대한 귀중한 통찰력을 얻고 이러한 모범 사례를 SAP 환경에 적용하는 방법을 알아보세요.

다음의 허가를 받아 복제됨시오스