SIOS SANless clusters High-availability Machine Learning monitoring
Oracle 데이터베이스 마이그레이션은 어려운 작업일 수 있습니다. 프로세스는 종종 복잡하고 비용이 많이 들 수 있습니다. 그러나 때로는 마이그레이션이 불가피합니다. 지원 및 라이선스 고려 사항이 함께 통합되어 마이그레이션이 필수인 경우 특히 그렇습니다. 그리고 비즈니스 크리티컬 데이터베이스를 마이그레이션할 때 고가용성 보호를 제공하여 가동 중지 시간을 방지하는 것이 중요하며, 이로 인해 수익과 생산성이 손실됩니다. Oracle은 Oracle Database 12c에 대한 지원이 곧 종료될 것이라고 발표했습니다. 따라서 Oracle Database 12c를 실행하는 조직은 마이그레이션에 대한 임박한 요구 사항에 직면하게 됩니다.
오늘날과 같이 경쟁이 치열하고 상시 가동되는 글로벌 경제에서 가동 중지 시간은 현대 비즈니스에서 그 어느 때보다 많은 비용을 초래합니다. 조직은 생산성 및 수익 손실 외에도 비즈니스 크리티컬 시스템, 데이터베이스 및 애플리케이션이 안정적이고 우수한 고객 경험을 제공할 수 없는 경우 고객을 잃을 위험이 있습니다. SIOS의 이 기술 요약은 비즈니스 크리티컬 애플리케이션에서 고가용성을 달성하는 복잡성에 대해 설명합니다.
이것은 논의 할 것입니다 일반 로드 밸런서 애플리케이션 복구 키트 (ARK) Linux용 SIOS Lifekeeper 및 특히 Google Cloud에서 구성하는 방법 SIOS ARK는 플랫폼 또는 애플리케이션 인식을 추가하는 SIOS LifeKeeper 제품에 대한 플러그인입니다.
이 블로그는 2노드 NFS 클러스터를 사용하는 방법과 이들이 제공하는 NFS 내보내기가 로드 밸런서를 통해 궁극적으로 액세스할 수 있는 방법을 보여줍니다.
SIOS는 SIOS LifeKeeper에서 클라이언트 리디렉션을 용이하게 하기 위해 이 ARK를 만들었습니다. GCP에서 실행되는 클러스터 .
GCP는 라우터 자체 IP 주소에 대한 브로드캐스트 요청인 무상 ARP를 지원하지 않기 때문에 클라이언트는 기존 클러스터 가상 IP 주소에 직접 연결할 수 없습니다. 대신 클라이언트는 로드 밸런서에 연결해야 하며 로드 밸런서는 트래픽을 활성 클러스터 노드로 리디렉션합니다. GCP는 레이어 4 TCP, 레이어 4 UDP 또는 레이어 7 HTTP/HTTP에서 작동하는 별도의 로드 밸런서 솔루션을 구현합니다. 로드 밸런서는 다음을 결정할 수 있는 상태 프로브인 비공개 또는 공개 프런트엔드 IP를 갖도록 구성할 수 있습니다. 노드가 활성 상태이고 일련의 백엔드 IP 주소(클러스터의 각 노드에 대해) 및 수신/발신 네트워크 트래픽 규칙입니다.
일반적으로 상태 프로브는 애플리케이션의 활성 포트를 모니터링하고 해당 애플리케이션이 활성 상태인 노드를 결정합니다. SIOS 일반 로드 밸런서 ARK는 활성 노드가 사용자 정의 포트에서 수신 대기하도록 구성됩니다. 그런 다음 이 포트는 GCP 부하 분산기에서 상태 프로브 포트로 구성됩니다. 이렇게 하면 활성 클러스터 노드가 TCP 상태 확인 프로브에 응답하여 자동 클라이언트 리디렉션을 활성화할 수 있습니다.
GCP 포털 내에서 부하 분산 선택
이 인스턴스에서 우리는 TCP 로드 밸런싱을 원합니다. 로드 밸런서를 만들고 이름과 함께 배포할 리소스 그룹을 선택합니다. 저는 클러스터 유형과 일치하는 이름을 사용하고 싶습니다. 예를 들어 IMA-NFS-LB와 함께 로드 밸런서를 사용하면 두 IMA-NFS 노드 앞에 배치됩니다.
이것이 인터넷 연결인지 VPC 내부인지 결정할 수 있습니다. 이 경우 내 VPC 내에서만 사용하기 위해 내 NFS 서버를 전면에 내도록 내부 전용 로드 밸런서를 구성하고 있습니다.
이름, 지역 등이 무엇인지 결정하면 백엔드 구성을 할당하라는 메시지가 표시되며, 이를 위해서는 프런트엔드할 HA 노드가 포함된 인스턴스 그룹이 필요합니다.
인스턴스 그룹을 할당했으면 상태 확인을 정의합니다. 이것은 Lifekeeper 일반 로드 밸런서 구성에서 사용할 포트와 일치하는 포트입니다. 이 경우에는 54321을 사용하고 있습니다.
다시 말하지만 포트 번호는 Lifekeeper와 함께 사용되므로 주의하십시오.
건강 기준의 기본값을 그대로 사용했습니다.
로드 밸런서에 대한 백엔드 구성 정보 및 상태 확인이 입력되면 프론트엔드 구성을 정의해야 합니다. 이는 로드 밸런서에 대해 생성하려는 서브넷, 리전 및 IP로 구성됩니다.
당신은 당신의 IP를 구성할 것이고 이것은 당신이 보호하고 있는 Lifekeeper IP와 일치할 것입니다.
구성에 만족하면 구성을 검토하거나 간단히 만들기를 클릭할 수 있습니다.
"만들기"를 선택하면 GCP가 로드 밸런서 배포를 시작합니다. 이 작업에는 몇 분이 소요될 수 있으며 완료되면 구성이 SIOS Protection Suite로 이동합니다.
이 블로그에서는 SPS-L을 사용하여 보호하도록 3개의 NFS 내보내기를 구성했으며, 3개의 내보내기는 GCP 부하 분산기의 프런트엔드 IP와 동일한 IP를 사용하도록 구성했습니다. 나는 사용하고있다 데이터 키퍼 내보내기에 저장된 데이터를 복제합니다.
첫 번째 단계는 스크립트를 얻는 것입니다. 가장 간단한 방법은 wget을 사용하는 것이지만 winscp 또는 유사한 도구를 사용하여 전체 패키지를 다운로드하고 rpm을 노드에 직접 업로드할 수도 있습니다. Lifekeeper 클러스터의 모든 노드에 핫픽스를 설치해야 합니다.
전체 복구 키트는 여기에서 얻을 수 있습니다. http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1 wget으로 부품을 찾을 수 있습니다. wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt 다운로드가 완료되면 FTP 사이트에 기록된 값과 MD5 합계를 확인합니다.
다음과 같이 RPM을 설치합니다. rpm -ivh 스틸아이-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm 다음을 실행하여 설치가 성공했는지 확인하십시오. rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172 어떤 이유로 RPM을 제거해야 하는 경우 다음을 실행하여 수행할 수 있습니다. rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64 아래는 이미 구성한 세 가지 NFS 내보내기를 보여주는 GUI입니다.
내에서 우리가 해야 할 일 SIOS 보호 제품군 SIOS에서 제공하는 Hotfix 스크립트를 사용하여 Load Balancer를 정의합니다.
먼저 새 리소스 계층을 만들고 드롭다운에서 일반 응용 프로그램을 선택합니다.
/opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/에 있는 restore.pl 스크립트를 정의합니다.
/opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/에 있는 remove.pl 스크립트를 정의하십시오.
/opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/에 있는 quickCheck 스크립트를 정의하십시오.
로컬 복구 스크립트가 없으므로 이 입력을 지워야 합니다.
애플리케이션 정보를 묻는 메시지가 표시되면 Healthcheck 포트에서 구성한 것과 동일한 포트 번호(예: 54321)를 입력하려고 합니다.
서비스가 생성되면 서비스를 제공하도록 선택할 것입니다.
리소스 태그는 SPS-L GUI에 표시되는 이름입니다. 저는 쉽게 식별할 수 있는 이름을 사용하고 싶습니다.
모든 것이 올바르게 구성된 경우 "END 성공적인 복원"이 표시되면 리소스를 두 노드 중 하나에서 호스팅할 수 있도록 이를 다른 노드로 확장할 수 있습니다.
두 노드로 확장한 후 완료된 로드 밸런서 구성을 보여줍니다.
이 클러스터의 마지막 단계는 세 가지 NFS 내보내기에 대한 하위 종속성을 생성하는 것입니다. 즉, Datakeeper 미러 및 IP로 완료된 모든 NFS 내보내기는 로드 밸런서에 의존합니다. 활성 노드에서 심각한 문제가 발생하면 이러한 모든 리소스가 다른 작동 중인 노드로 장애 조치됩니다.
위의 Lifekeeper GUI에서 완성된 계층 구조입니다. 아래는 NFS 내보내기, IP, 파일 시스템 및 DataKeeper 복제 볼륨을 로드 밸런서 리소스의 자식으로 보여주는 확장된 GUI 보기를 보여줍니다.
이것은 GCP에서 SIOS LifeKeeper를 사용하여 간단한 NFS 클러스터를 보호하는 방법의 한 예일 뿐입니다. 보호해야 하는 모든 비즈니스 크리티컬 애플리케이션에도 동일한 개념이 적용됩니다. GCP 로드 밸런서(인터넷 또는 내부)가 현재 애플리케이션을 호스팅하는 노드를 결정할 수 있도록 SIOS에서 제공하는 로드 밸런서 ARK를 활용하기만 하면 됩니다.
방법에 대해 생각하고 SAP의 다운타임 감소 초기 솔루션 설계 중에 방문해야 하는 중요한 주제입니다. 기존 SAP 환경을 변경할 수 있으며 가동 중지 시간이 문제가 되는 기존 프로덕션 환경에서는 더 까다로울 수 있습니다.
SAP 환경에는 단일 실패 지점으로 간주될 수 있는 몇 가지 일반적인 구성 요소가 있습니다. ASCS(중앙 서비스), HANA DB, NFS 노드 및 SAP 애플리케이션 서버. 이상적으로는 고가용성 구성에서 중복 서버를 사용하여 보호해야 합니다.
● 가동 중지 시간 최소화 ● 데이터 손실 제거 ● 데이터 무결성 유지 ● 유연한 구성 활성화 오늘날의 현대적인 클라우드 환경에서 기본 하드웨어의 인프라는 일반적으로 여러 중복 NIC, 중복 스토리지 및 하드웨어 가용성 영역을 사용하여 장애로부터 잘 보호되지만 여전히 그렇지는 않습니다. SAP 응용 프로그램이 실행되고 요청에 응답한다고 보장하지 않습니다.
사용 고가용성 SIOS Protection Suite와 같은 솔루션은 로컬 디스크 복제와 결합된 지능형 고가용성을 도입하여 SAP 애플리케이션 및 서비스가 지속적으로 모니터링되고 보호되며 장애가 감지되면 자동으로 중복 하드웨어로 전환할 수 있는 기능을 제공합니다.
이제 HA로 보호되지 않는 SAP 구성의 간단한 예를 고려해 보겠습니다. 다음과 같이 보일 수 있습니다(그림 1).
이 환경이 고객에게 의류를 판매하는 데 사용되는 웹 서버의 트랜잭션을 처리하는 데 사용되는 경우 SAP는 이러한 트랜잭션을 기반으로 판매 처리, 주문 추적, 재고 추적 및 다중 자동 주문 제공 등에 사용됩니다.
이제 이 영업 처리 환경(위 그림)이 HA가 없는 클라우드에서 구성되었다고 가정해 봅시다. 설계자가 클라우드 환경에서 고도로 이중화된 하드웨어가 장애로부터 보호하기에 충분하다고 생각했기 때문입니다.해당 HANA DB에 문제가 발생하여 종료되는 경우 데이터베이스를 백업하고 실행하는 데 일반적으로 필요한 단계를 살펴보겠습니다. ● HANA가 HANA System Replication으로 구성되어 있어도 보조 HANA DB 시스템으로의 장애 조치는 자동화되지 않습니다. 이를 위해서는 HANA를 알고 있는 사람이 오류를 감지하고 중단을 통보한 후 수정해야 합니다.
● 웹 서버의 실시간 거래는 문제가 해결될 때까지 중단됩니다. 이 작은 의류 소매업체가 웹 기반 판매로 연간 약 1000만 달러를 거래하는 경우, 이는 1년 동안 균등한 매출로 시간당 약 1150달러에 해당합니다. 피크 시간은 시간당 비용이 훨씬 더 많이 듭니다.
IBM의 이 보고서 시간당 평균 다운타임 비용은 $10,000입니다.
그림 2: HA/DR이 포함된 SAP 환경 HA 소프트웨어가 사용 중이었다면(그림 2), HANA DB 장애 조치가 자동으로 이루어지고 웹 서버에 대한 중단이 구성된 시간 초과 내에 있었을 것이며 판매 손실은 전혀 없었을 것입니다. 경보가 발생하고 시스템 다운 상황보다 여유롭게 원인을 살펴보고 진단할 수 있습니다.
고객 규모를 확장하면 시스템 다운 상황이 발생하면 수십만 달러의 비용이 발생하고 해결하는 데 상당한 인력 리소스가 소모될 가능성이 매우 높습니다.
또 다른 IBM 보고서 응답자의 44%가 격월로 계획되지 않은 정전을 경험했으며 또 다른 35%는 매월 계획되지 않은 정전을 경험했다고 밝혔습니다.
계획된 중단 자체는 또 다른 잠재적인 문제로 응답자의 46%가 월간 계획된 중단을 보고했으며 추가로 29%는 연간 계획된 중단을 보고했습니다. HA 소프트웨어로 애플리케이션과 서비스를 보호하면 유지 관리 활동 중에 서비스를 실행 중인 시스템으로 이동하여 이러한 계획된 중단을 완화할 수도 있습니다.
에 대해 자세히 알아보기 SAP 및 S/4HANA에 대한 고가용성 .
