SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 제작품
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 뉴스 및 이벤트
  • 서버 클러스터 단순화
  • 성공 사례
  • 저희에 게 연락
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

Mitsubishi Motors는 고가용성 보호를 위해 LifeKeeper를 사용하여 중요 시스템을 클라우드로 이전했습니다.

2월 2, 2024 by Jason Aw Leave a Comment

Mitsubishi Motors Moves Critical Systems to the Cloud with LifeKeeper for High Availability Protection

Mitsubishi Motors는 고가용성 보호를 위해 LifeKeeper를 사용하여 중요 시스템을 클라우드로 이전했습니다.

Mitsubishi Motors Corporation은 새로운 클라우드 기반 시스템으로 3개 위치의 창고 관리 시스템을 개편하면서 복잡성을 추가하거나 성능을 저하시키지 않고 고가용성을 제공할 수 있는 새로운 방법이 필요했습니다.

“문제가 발생하더라도 LifeKeeper는 기본 서버 노드에서 보조 서버 노드로 자동으로 장애 조치됩니다.시스템을 즉시 시스템화하고 사용자가 눈에 띄는 지연 없이 작업을 계속할 수 있도록 하여 IT 시간을 절약하고 고객의 서비스 중단을 제거합니다.”

Mitsubishi Motors 글로벌 IT 사업부 비즈니스 IT 부서 관리자 Hiromasa Tsuboshima는 이렇게 말했습니다.

환경

각 Mitsubishi Motors 창고는 딜러가 판매하는 바닥 매트, 루프랙 등 자동차 부품 및 액세서리에 대한 주문 및 재고를 처리하는 관리 시스템을 사용합니다. 부품 및 소모품 수령, 딜러로부터의 국내 및 해외 주문에 대한 배송 관리, 창고 위치 자체 내에서 재고 관리 및 할당을 관리합니다.

레거시 시스템은 문제 해결에 IT 시간을 낭비하고 운영을 자주 중단시키는 문제가 발생하기 쉬운 노후화된 온프레미스 서버 하드웨어에서 실행되었습니다. 기존 시스템은 가동 중지 시간을 줄이기 위해 하드웨어 제조업체의 독점 이중화를 사용했습니다. 레거시 시스템에 문제가 발생하면 IT 직원은 문제가 해결될 때까지 수동으로 시스템을 중지하고 중복 하드웨어로 작업을 전환해야 했습니다. 이 프로세스에는 IT 직원의 시간이 2~4시간이 소요되었습니다.

미쓰비시 자동차는 정해진 승인 기간 내에 주문한 모든 부품이나 액세서리가 다음날 대리점에 배송되도록 해야 합니다. 따라서 이러한 미션 크리티컬 시스템의 가동 중단 시간이 짧더라도 비즈니스에 심각한 영향을 미칠 수 있습니다.

창고 관리 시스템은 모든 주문이 배송 일정에 맞춰 적시에 처리되도록 하는 데 중요한 역할을 합니다. 예를 들어, 오후 4시 29분에 입력된 주문의 익일 배송을 보장하려면 창고 관리 시스템은 해당 주문이 당일 마지막 트럭이나 항공편에 실릴 수 있도록 오후 4시 40분까지 이를 처리하고 표시해야 합니다. 이와사키는 “10분 안에 회복해야 한다”고 말했다.

도전

Mitsubishi Motors Corporation의 글로벌 IT 사업부 비즈니스 IT 부서 관리자인 Hiromasa Tsuboshima는 다음과 같이 말했습니다. “6개 창고 중 3개 창고의 기존 시스템은 2012년부터 하드웨어로 설치되어 있었습니다. 우리는 이를 새로운 시스템으로 교체해야 했습니다. IT 리소스를 확보하고 운영에 미치는 부정적인 영향을 줄입니다.” 새로운 클라우드 기반 창고 시스템을 위한 고가용성 솔루션을 찾는 것이 프로젝트 성공에 매우 중요했습니다. Mitsubishi Motors Corporation의 글로벌 IT 부문 비즈니스 IT 부서 구성원인 Satoshi Iwasaki는 다음과 같이 말했습니다. “전사적 정책에 따르면 우리는 새로운 시스템을 구축할 때마다 기존 온프레미스 시스템에서 퍼블릭 클라우드로 마이그레이션해야 합니다. ”

고가용성 소프트웨어

창고 관리 시스템을 퍼블릭 클라우드로 마이그레이션할 때 Mitsubishi Motor는 고가용성을 위해 Linux용 SIOS LifeKeeper를 추천한 외부 IT 컨설턴트와 상담했습니다. “과거 경험에서 우리는 항상 고가용성을 위해 하드웨어 솔루션을 사용했습니다.”라고 Iwasaki 씨는 말했습니다. “HA용 소프트웨어 사용에 대해 SIOS 담당자에게 심층적인 질문을 많이 했는데, SIOS는 정확하고 완전한 답변을 제공하여 SIOS LifeKeeper에 대한 신뢰를 구축했습니다.”

LifeKeeper를 선택하기로 결정한 또 다른 주요 요인은 Mitsubishi의 특정 창고 시스템 요구 사항에 맞는 애플리케이션 인식 복구 키트(ARK)를 제공하는 LifeKeeper 전문 서비스 옵션이었습니다.

SIOS ARK를 사용하면 LifeKeeper가 잠재적인 가동 중지 문제에 대해 전체 애플리케이션 스택을 모니터링할 수 있습니다. 또한 보조 노드에서의 원활한 작동을 위해 모범 사례에 따라 애플리케이션 장애 조치를 조정합니다. Iwasaki 씨는 “우리는 요구 사항을 충족하기 위해 LifeKeeper를 사용자 정의하고 개발할 수 있었고 SIOS는 우리의 모든 요청에 ​​응답할 수 있었습니다.”라고 말했습니다.

빠른 자동 장애 조치

“문제가 발생하더라도 LifeKeeper는 즉시 기본 서버 노드에서 보조 노드로 자동으로 장애 조치를 수행하며 사용자에게 눈에 띄는 지연 없이 작업이 계속됩니다. IT 시간을 절약하고 고객 서비스 중단을 방지합니다.”라고 Tsuboshima 씨는 말했습니다. Tsuboshima 씨는 글로벌 IT 부문의 일부 시스템을 감독하는 일을 담당하고 있습니다. 업그레이드 프로젝트 이전에 그는 즉각적인 주의가 필요한 장애 알림을 밤낮으로 수신하곤 했습니다. 현재는 장애가 발생하는 경우 장애 조치 알림을 받기만 하면 시스템이 개입 없이 계속 작동됩니다. SIOS 솔루션은 Tsuboshima 씨와 나머지 IT 팀의 귀중한 시간을 절약하고 서비스 중단을 제거했습니다.

결과

LifeKeeper를 통해 고가용성을 보장하면서 창고 관리 시스템을 클라우드로 이전함으로써 얻을 수 있는 이점은 2020년 팬데믹에 대한 대응으로 분명해졌습니다. ‘클라우드에 시스템을 구축함으로써 시스템을 원격으로 관리할 수 있게 되었습니다. 이와사키 씨는 “기존 온프레미스 시스템을 계속 사용했다면 코로나19 비상 상황 중에 문제를 해결하거나 시스템을 관리하기 위해 사무실에 출근해야 하는 상당한 추가 위험에 직면했을 것입니다.”라고 말했습니다.

Mitsubishi Motors는 계속해서 퍼블릭 클라우드로 전환하고 있지만, 많은 시스템이 여전히 메인프레임을 사용하고 있습니다. Iwasaki 씨는 “미션 크리티컬 시스템을 이러한 호스트 시스템에서 클라우드로 이전하는 것을 고려하면서 LifeKeeper를 통해 고가용성 보호를 모색할 것입니다.”라고 말했습니다. 앞으로는 회사에 추천할 예정입니다.”

Linux용 SIOS LifeKeeper에 대해 자세히 알아보기

자세히 알아보기SIOS LifeKeeper, SIOS DataKeeper 및 SIOS 애플리케이션 복구 키트를 포함한 SIOS 보호 제품군입니다.

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

Filed Under: 서버 클러스터 단순화

DataKeeper Cluster Edition(DKCE 클러스터)을 설정하는 방법

1월 30, 2024 by Jason Aw Leave a Comment

How to Set Up a DataKeeper Cluster Edition (DKCE Cluster)

DataKeeper Cluster Edition(DKCE 클러스터)을 설정하는 방법

DKCE 클러스터란 무엇입니까?

DKCE는 다음의 약어입니다.DataKeeper 클러스터 에디션. DKCE는 DataKeeper의 사용과 다음 기능을 결합한 SIOS 소프트웨어입니다.Windows 장애 조치 클러스터링제공하다고가용성마이그레이션 기반 데이터 복제를 통해

DKCE 클러스터를 생성하는 단계

이 예에서는 세 번째 노드가 노드 다수를 유지하는 3노드 클러스터를 설정하겠습니다.

1 단계:DKCE 클러스터를 설정하려면 시스템의 2/3에 DataKeeper가 설치되어 있어야 합니다. 빠른 시작 가이드에 따라 설치를 완료하려면 다음 링크를 클릭하세요.https://docs.us.sios.com/dkce/8.10.0/en/topic/datakeeper-cluster-edition-quick-start-guide

2 단계:서버 관리자에서 관리하려는 서버를 추가하세요. 클러스터에 추가하려는 모든 서버에서 이 작업을 수행해야 합니다.

서버에서 서버 관리자로 이동하세요.

‘관리할 다른 서버 추가’를 클릭하세요.

여기에 이름으로 서버를 추가했습니다. 이 방법으로 수행하려면 C:\Windows\System32\drivers\etc\hosts에 있는 호스트 파일에서 시스템 이름과 IP 항목을 확인해야 합니다.

모든 서버를 추가한 후 서버 관리자에서 “모든 서버”로 이동하여 확인할 수 있습니다.

3단계:winRM 오류가 나타날 수 있습니다. 이를 우회하려면 PS에서 관리자로 이 명령을 실행하세요. 클러스터의 서버를 신뢰할 수 있는 호스트로 추가하려면 이 명령을 실행하세요. 이 명령은 클러스터의 모든 시스템에서 실행되어야 합니다.

세트 항목 WSMan:\localhost\Client\TrustedHosts -값 ‘<서버 1 이름>,<서버 2 이름>’

4단계:장애 조치 클러스터링 설치

따르다장애 조치 클러스터링을 설치하려면 다음 단계를 따르세요..

5단계:장애 조치 클러스터 관리자로 이동

6단계:“클러스터 생성”을 클릭하세요.

7단계:그런 다음 클러스터에 있어야 하는 서버를 추가하고 각 항목 다음에 “추가”를 클릭합니다.

8단계:목록은 다음 이미지의 목록과 유사해야 합니다.

9단계:유효성 검사 테스트에 대해 “모든 테스트 실행”을 선택하고 다음을 클릭합니다.

10단계:테스트가 완료되면 “마침”을 클릭하세요.

11단계:클러스터 이름을 “Cluster1″로 지정했습니다. “다음”을 클릭하세요.

12단계:“클러스터에 모든 적합한 스토리지 추가”가 선택되어 있는지 확인하고 “다음”을 클릭합니다.

13단계:12단계가 완료되면 ‘마침’을 클릭하세요.

14단계:장애 조치 클러스터 관리자에서 클러스터는 처음에는 오프라인 상태입니다. 사용하지 않는 IP를 할당하여 온라인으로 전환하겠습니다. “클러스터 코어 리소스”에서 IP 주소 리소스를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.

속성 패널에서 내 서브넷 마스크는 /28이므로 12.0.0.14 범위 내에서 사용 가능한 IP를 선택하겠습니다. “적용”을 클릭하세요

“클러스터 핵심 리소스”에서 클러스터를 마우스 오른쪽 버튼으로 클릭하고 “온라인으로 가져오기”를 선택합니다.

이제 리소스가 온라인 상태여야 합니다.

15단계:DataKeeper로 이동

16단계:Job을 마우스 오른쪽 버튼으로 클릭하고 “Create Job”을 클릭하여 첫 번째 미러 생성을 시작합니다.

작업 이름을 “job1″로 지정하고 “Create Job”을 클릭합니다.

데이터를 복제할 소스와 볼륨을 선택합니다. Box1을 소스로 선택하고 볼륨 D를 선택했습니다. “다음”을 클릭하세요.

다음으로 대상이 될 서버와 볼륨을 선택합니다. 저는 Box2와 볼륨 D를 선택했습니다.

생성한 볼륨을 WSFC 볼륨으로 자동 등록할지 묻는 메시지가 표시됩니다. 이 볼륨을 고가용성으로 만들려면 “예”를 선택하세요.

이제 DataKeeper에서 볼륨이 현재 미러링되고 있음을 확인할 수 있습니다.

17단계:장애 조치 클러스터 관리자에서 저장소, 디스크로 차례로 이동합니다. 자동 등록한 볼륨이 WSFC임을 확인할 수 있습니다.

18단계:확인해야 할 Owner를 확인해 보겠습니다. 볼륨을 마우스 오른쪽 버튼으로 클릭하고 “속성”을 클릭합니다.

증인이 되어 노드 다수를 유지하려면 세 번째 사람이 필요하므로 Box3을 선택 해제하거나 선택 해제 상태를 유지해야 합니다.

19단계:이제 장애 조치 클러스터 관리자를 통해 마이그레이션을 테스트할 수 있습니다. 파일 탐색기로 이동하여 현재 미러링 중인 볼륨에 새 텍스트 파일을 만듭니다. 소스에서 이 작업을 수행하세요.

장애 조치 클러스터 관리자로 이동하여 “DataKeeper 볼륨 D”를 클릭하고 작업 창에서 “사용 가능한 저장소 이동”을 선택합니다.

“최적의 노드”를 마우스 오른쪽 버튼으로 클릭합니다. 그러면 자동으로 대상으로 마이그레이션됩니다.

장애 조치 클러스터 관리자에서 “DataKeeper 볼륨 D”의 소유자가 이제 대상 노드인지 확인합니다.

DataKeeper로 이동하여 대상이 이제 소스인지, 그 반대인지 확인하십시오.

성공적인 DKCE 클러스터 설정

DKCE 클러스터 설정을 완료했습니다.

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

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

 

Filed Under: 서버 클러스터 단순화

중요한 교육 애플리케이션에 대한 액세스 보장

1월 24, 2024 by Jason Aw Leave a Comment

Ensuring Access To Critical Educational Applications

중요한 교육 애플리케이션에 대한 액세스 보장

교육과 정보 기술(IT)은 점점 더 떼어놓을 수 없게 되었습니다. 문제의 IT가 강의실 화이트보드를 지원하는 애플리케이션인지, 대학 등록 시스템을 지원하는 데이터베이스인지, 학습 관리 시스템(LMS)인지, 연구실, 기숙사, 식당에 대한 학생 접근을 제어하는 ​​건물 유지 관리 시스템인지 여부 – 핵심 구성 요소인 경우 IT 인프라가 갑자기 어두워지면 교사, 관리자, 학생 모두 자신이 달성해야 할 작업을 수행할 수 없습니다. 기관의 임무가 중단되었습니다. 방해가 너무 잦아 학생, 교사, 행정관의 경험이 훼손되면 기관 자체의 평판도 훼손될 수 있습니다.

교육 경험에 중요한 애플리케이션의 고가용성(HA)을 보장하도록 설계된 IT 인프라는 어떤 이유로든 시스템이 응답하지 않을 경우 발생할 수 있는 중단 및 평판 손실 위험을 최소화할 수 있습니다. 이 경우 HA 인프라는 핵심 애플리케이션의 가용성을 99.99% 이상 보장할 수 있는 인프라로 정의됩니다. 다르게 말하면, 중요한 애플리케이션이 한 달에 4분 이상 예기치 않게 오프라인 상태가 되지 않는다는 의미입니다.

HA를 어떻게 달성합니까? 그 질문은 쉽게 대답될 수 있지만, 당신이 물어봐야 할 질문은 그것만이 아닙니다. 마찬가지로 중요한 것은 HA 구성을 보장할 정도로 중요한 애플리케이션은 무엇입니까? 기본적으로 HA용으로 구성된 IT 인프라에는 지리적으로 구별되는 위치(기본 서버가 온프레미스 또는 별도의 가용성에 있는 경우 원격 데이터 센터일 수 있음)에 위치한 하나 이상의 보조 서버 및 스토리지 하위 시스템 세트가 있습니다. 서버가 클라우드에 있는 경우 영역 [AZ]). 어떤 이유로 인해 기본 서버에서 실행 중인 응용 프로그램이 응답을 중지하는 경우 응용 프로그램을 관리하는 HA 소프트웨어는 즉시 해당 응용 프로그램을 보조 서버로 장애 조치합니다. 여기서 중요한 응용 프로그램은 기본 서버가 응답을 멈춘 지점부터 다시 시작됩니다. 복제하려는 기본 서버의 크기 및 성능 특성에 따라 해당 보조 서버의 비용이 많이 들 수 있으므로 모든 교육용 애플리케이션을 HA용으로 구성할 가능성은 거의 없습니다. HA에 대한 투자가 필요한 애플리케이션을 결정하고 나면 HA 환경을 구축해야 하는 위치를 알게 됩니다.

고가용성 달성을 위한 선택

보호하려는 애플리케이션을 선택하고 나면 HA를 달성하기 위한 옵션이 더 명확해집니다. Windows 또는 Linux에서 실행됩니까? 데이터베이스 관리 시스템(DBMS)에 HA 구성이 기본적으로 지원됩니까? 그렇다면 그 한계는 무엇입니까? 예를 들어 중요한 애플리케이션이 Windows 및 SQL Server에서 실행 중인 경우 SQL Server 자체의 AG(가용성 그룹) 기능을 사용하여 HA를 활성화할 수 있습니다. 또는 SQL Server의 AG 서비스가 제공하지 않는 옵션을 제공하는 타사 SANless 클러스터링 도구를 사용하여 HA를 구성할 수 있습니다. 여러 공급업체의 데이터베이스 서버를 보호하려는 경우 또는 중요한 애플리케이션 중 일부는 Windows에서 실행되고 다른 애플리케이션은 Linux에서 실행되는 경우 여러 DBMS 및 OS를 지원하는 HA 솔루션을 사용하면 HA 관리 기능이 더욱 향상됩니다. 플랫폼. 다양한 DBMS 및 OS 플랫폼을 수용하는 클러스터 솔루션을 선택하면 여러 데이터베이스 기반 HA 서비스를 동시에 처리할 때 발생할 수 있는 복잡성과 번거로움에 비해 관리가 단순화됩니다.

데이터베이스 기반 HA 솔루션을 통한 고가용성 보장

SQL Server의 AG 기능과 같은 데이터베이스 기반 HA 솔루션을 사용하는 경우 소프트웨어는 기본 SQL Server 데이터베이스의 모든 데이터를 보조 시스템 서버에 있는 해당 데이터베이스의 동일한 인스턴스에 동기식으로 복제합니다. 어떤 이유로 인해 기본 서버가 응답을 중지하는 경우 AG 구성 요소의 모니터링 기능으로 인해 자동으로 보조 서버가 대신하게 됩니다. AG 기능은 모든 데이터를 실시간으로 복제하기 때문에 보조 서버가 즉시 인계받을 수 있으며 서비스 중단이나 데이터 손실이 거의 없습니다.

많은 데이터베이스 기반 HA 도구는 비슷한 방식으로 작동합니다. 그러나 데이터베이스 기반 접근 방식을 고려할 때 몇 가지 주의 사항이 있습니다. HA 서비스가 DBMS 자체에 번들로 제공되는 경우 해당 DBMS와 관련된 데이터만 복제할 수 있습니다. 다른 중요한 데이터가 기본 서버에 있는 경우 데이터베이스 기반 HA 시나리오에서는 해당 데이터가 보조 서버로 복제되지 않습니다. 데이터베이스 네이티브 서비스가 복제하는 항목에는 다른 제한 사항이 있을 수도 있습니다. 예를 들어 SQL Server Standard Edition에 번들로 제공되는 기본 AG 기능을 사용하는 경우 각 AG는 단일 SQL 데이터베이스만 단일 보조 위치에 복제할 수 있습니다. 애플리케이션에 여러 SQL 데이터베이스가 포함된 경우 여러 기본 AG를 만들 수 있지만 장애 조치 상황에서 각 AG가 동시에 장애 조치되는지 여부를 제어할 수 없으며 그렇지 않으면 문제가 발생할 수 있습니다. 이 제한을 해결하는 한 가지 방법은 SQL Server Enterprise Edition에 번들로 포함된 Always On AG 기능을 사용하는 것입니다. 이를 통해 여러 SQL 데이터베이스를 여러 보조 서버로 복제할 수 있지만 애플리케이션이 그렇지 않은 경우 라이선스 측면에서 비용이 매우 많이 들 수 있습니다. 그렇지 않으면 SQL Server Enterprise Edition의 기능을 사용하십시오.

다른 데이터베이스 기반 HA 솔루션에도 비슷한 제약이 있을 수 있으므로 이러한 접근 방식에 투자하기 전에 이를 이해해야 합니다.

SANless 클러스터링을 통한 고가용성 보장

HA에 대한 데이터베이스 기반 접근 방식의 대안으로 타사 도구를 사용하여 SANless 클러스터를 생성할 수 있습니다. 위에서 설명한 AG 구성과 마찬가지로 SANless 클러스터링 소프트웨어는 기본 서버에서 보조 서버로 데이터의 동기식 복제를 자동화합니다. 또한 기본 서버가 응답하지 않는 경우 보조 서버에 대한 즉각적인 장애 조치를 조정합니다. 장애 조치에는 단 몇 초밖에 걸리지 않으므로 중요한 애플리케이션에 대한 관리자, 교직원 및 학생의 액세스는 사실상 중단 없이 유지됩니다.

SANless 클러스터링과 데이터베이스 기반 접근 방식 간의 중요한 차이점은 실용적인 세부 사항에 있습니다. SANless 클러스터링 접근 방식은 데이터베이스에 구애받지 않습니다. 지정된 스토리지 볼륨의 모든 데이터를 복제합니다. 여기에는 여러 공급업체의 여러 데이터베이스, 텍스트 파일, 비디오 파일 또는 가용성이 중요한 기타 교육 자산이 포함될 수 있습니다. HA에 대한 데이터베이스 기본 접근 방식을 사용하기 위해 더 비싼 데이터베이스 버전으로 업그레이드해야 하는 경우 기관에서는 이를 통해 상당한 비용을 절약할 수 있습니다. 마지막으로 앞서 언급한 것처럼 여러 운영 환경에서 실행되는 애플리케이션과 데이터를 보호하려는 경우 SANless 클러스터링 접근 방식이 개별 데이터베이스 기반 접근 방식보다 관리하기가 더 쉬울 수 있습니다. SANless 클러스터링을 사용하면 Windows 또는 Linux 환경에서 HA를 보장할 수 있으며, 이를 통해 운영 환경마다 다른 데이터베이스 기본 접근 방식의 배포에 수반되는 복잡성을 제거할 수 있습니다.

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

Filed Under: 서버 클러스터 단순화

웹 세미나: 클라우드의 재해 복구: SQL Server의 과제와 전략 이해

1월 19, 2024 by Jason Aw Leave a Comment

Webinar Disaster Recovery in the Cloud Understanding Challenges and Strategies for SQL Serve

웹 세미나: 클라우드의 재해 복구: SQL Server의 과제와 전략 이해

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

클라우드에서 고가용성(HA)과 재해 복구(DR)를 보장하는 것은 많은 조직에게 어려운 일이 될 수 있습니다. 클라우드의 HA/DR과 관련된 과제에는 다양한 클라우드 공급업체의 다양한 도구 활용, 데이터 주권 고려 사항, 규정 준수 과제 및 지속적인 비용 관리의 복잡성이 포함됩니다.

이 웨비나에서는 중단 없는 서비스와 데이터 보호를 위한 중복성과 장애 조치의 중요성을 강조하면서 이러한 과제를 해결하는 방법을 논의하고, 클라우드 탄력성과 강력한 백업 및 DR 전략의 필요성에 대한 일반적인 오해를 살펴봅니다.

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

Filed Under: 서버 클러스터 단순화

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

1월 14, 2024 by Jason Aw Leave a Comment

Build High Availability with a HANA 3-Node HSR Cluster in AWS Using SIOS LifeKeeper

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가 제공하는자원그리고훈련우리의 모든 제품에 대해.

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

 

Filed Under: 서버 클러스터 단순화

  • « Previous Page
  • 1
  • …
  • 26
  • 27
  • 28
  • 29
  • 30
  • …
  • 112
  • Next Page »

최근 게시물

  • 고가용성(HA)이란 무엇인가요?
  • 금요일 밤의 시스템 충돌에서 살아남기: 초라한 베어메탈에서 완벽한 데이터 복제까지
  • Grounded: 암스테르담에서 열린 Percona Live에 참석하지 못한 것이 제게 HA에 대해 가르쳐준 것
  • SIOS LifeKeeper와 Red Hat 고가용성 추가 기능 비교:
  • 애플리케이션 복원력 현황: 2026 SIOS 고가용성 설문조사

가장 인기있는 게시물

우리의 메일 링리스트에 가입하세요

Copyright © 2026 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in