백서: SIOS Protection Suite를 사용하여 Amazon EC2에서 SAP 및 SAP S/4HANA 보호

백서: SIOS Protection Suite를 사용하여 Amazon EC2에서 SAP 및 SAP S/4HANA 보호

AWS에는 인프라 수준에서 가용성을 보장하기 위한 조항이 있지만 SAP 환경의 비즈니스에 중요한 특성으로 인해 더 많은 보호가 보장됩니다. 즉, 애플리케이션과 데이터베이스 계층에 특별한 주의를 기울여야 합니다. 이러한 추가 보호를 제공하기 위한 몇 가지 옵션이 있습니다.

이 백서에서는 AWS에서 Oracle Linux, Red Hat, SUSE 및 CentOS를 포함한 Linux 배포판에서 SAP 또는 SAP S/4HANA를 실행하기 위한 모범 사례를 살펴봅니다.

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

Microsoft 장애 조치 클러스터에 Amazon EBS 다중 연결을 사용할 때의 과제

Microsoft 장애 조치 클러스터에 Amazon EBS 다중 연결을 사용할 때의 과제

Amazon EBS 및 Microsoft 장애 조치 클러스터 개요

Amazon EBS 다중 연결 볼륨 및 Microsoft장애 조치 클러스터클라우드 컴퓨팅 및 데이터 관리 분야의 강력한 도구입니다. 그러나 이 두 기술을 통합하는 데에는 어려움이 따를 수 있습니다. 이 블로그 게시물에서는 Microsoft 장애 조치 클러스터에 Amazon EBS 다중 연결을 사용하는 것이 종종 최선의 선택이 아닌 이유를 자세히 설명합니다.

강력한 장애 조치 클러스터를 위한 단일 AZ 제약 조건

Amazon EBS 볼륨의 주요 제한 사항은 단일 가용 영역(AZ)으로 제한된다는 점입니다. 강력한 장애 조치 클러스터의 경우 여러 AZ에 인스턴스를 배포하는 것이 권장되는 모범 사례이며 EBS 볼륨에서는 직접 지원할 수 없습니다.

고가용성 SLA 문제

EBS 볼륨은99.9% 가용성 SLA, 이는 고가용성 솔루션에서 일반적으로 기대되는 99.99%에 미치지 못합니다. AWS는 여러 AZ에 인스턴스를 배포할 때 더 높은 SLA를 보장하며, 이는 단일 AZ 배포에는 적용되지 않는 이점입니다.

IO2 볼륨의 비용 영향

다중 연결 EBS 볼륨이 있는 Windows 장애 조치 클러스터에는 비슷한 크기와 성능의 GP3 볼륨보다 약 9배 더 비싼 IO2 볼륨을 사용해야 합니다. 이러한 비용 차이는 특히 대규모 배포의 경우 중요합니다.

AWS 클러스터 구성의 복잡성

건물AWS의 클러스터동일한 AZ에 노드가 있는 경우 Windows 클러스터에서 서로 다른 VIP(가상 IP 주소)를 지원하려면 AZ를 여러 서브넷으로 나누어야 합니다. 클러스터 노드 전체에서 단일 VIP를 공유할 수 없다는 점과 함께 이러한 복잡성으로 인해 구성 문제가 가중됩니다.

SIOS DataKeeper: 우수한 대안

SIOS 데이터 키퍼원하는 99.99% 가용성 SLA를 제공하면서 서브넷에 걸쳐 클러스터를 허용하는 우수한 솔루션으로 등장합니다. GPT3 디스크 사용을 포함하여 보다 유연한 저장소 옵션을 제공할 뿐만 아니라 훨씬 더 비용 효율적입니다. GPT3 디스크와 함께 SIOS DataKeeper를 사용하는 클러스터는 유사한 IO2 기반 클러스터 비용의 약 20%에 해당하며 향상된 가용성을 제공합니다.

SIOS를 통한 탁월한 고가용성

Microsoft 장애 조치 클러스터에서 Amazon EBS 다중 연결 볼륨을 사용하면 제한된 AZ 배포 옵션과 낮은 가용성 SLA부터 높은 비용과 증가된 구성 복잡성에 이르기까지 몇 가지 중요한 과제가 발생합니다. SIOS DataKeeper는 비용, 유연성 및 신뢰성의 균형을 보다 효과적으로 유지하는 강력한 대안을 제공합니다. 고가용성과 비용 효율성을 추구하는 조직의 경우 EBS 다중 연결 이상의 옵션을 탐색하는 것이 신중한 전략입니다.SIOS에 문의하세요자세한 내용은.

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

비디오: 애플리케이션 고가용성이 보편화될 것입니다 | SIOS 기술의 예측

비디오: 애플리케이션 고가용성이 보편화될 것입니다 | SIOS 기술의 예측

SIOS Technology는 Windows 및 Linux 시스템과 다양한 클라우드 플랫폼에서 고객에게 중요한 미션 크리티컬 데이터베이스, 애플리케이션 및 서비스에 대한 애플리케이션 가용성을 제공하는 고가용성(HA) 및 재해 복구(DR) 솔루션 회사입니다.카시우스 루에, SIOS Technology의 고객 경험 담당 부사장이 2024년 예측을 공유합니다.

애플리케이션에 대한 의존도가 계속 높아짐에 따라 IT 팀은 미션 크리티컬 애플리케이션 외에 전통적으로 필수적이지 않다고 간주되었던 애플리케이션에 대해 효율적인 고가용성 및 재해 복구를 제공해야 한다는 압박도 커질 것입니다. 이러한 변화로 인해 이러한 기대를 충족하기 위한 고가용성 소프트웨어 솔루션 및 서비스가 확장될 가능성이 높습니다.

더 많은 회사가 다양한 운영 체제를 통해 클라우드로 확장함에 따라 더 많은 팀이 다양한 운영 체제, 애플리케이션 및 클라우드 플랫폼을 다룰 것으로 예상됩니다. 팀은 복잡성을 줄이고 비용 효율성을 향상시키기 위해 다양한 운영 체제와 클라우드 환경에서 일관적인 애플리케이션과 솔루션을 찾을 것입니다.

HA 솔루션은 또한 운영 체제와 클라우드 환경 전반에 걸쳐 일관성을 유지해야 하며 클라우드에 구애받지 않는 HA를 향한 추진력을 보게 될 것입니다. 기업에는 단순하고, 자동화되고, 빠르고, 지능적인 HA 및 DR 솔루션이 필요합니다. 더 많은 조직이 클라우드로 마이그레이션함에 따라 프로세스에서 데이터가 손실되지 않도록 해야 합니다. HA 솔루션은 기존 시스템과 최신 시스템 간의 격차를 해소해야 합니다.

2024년에는 데이터 보존, 보안 액세스 제어 및 권한에 대한 초점이 높아져 조직이 고가용성 및 재해 복구 솔루션, 서비스 및 전략에 더욱 향상된 보안 조치를 통합하도록 유도할 것입니다. 수집되는 데이터의 양이 계속 증가함에 따라 조직에는 오류가 발생한 이유에 대한 추가 정보도 필요합니다. 자동화 및 조정 도구는 근본 원인 분석을 간소화하고 지능적인 대응을 제공하는 데 중심적인 역할을 할 가능성이 높습니다.

SIOS Technology는 내년에도 계속해서 고객에게 초점을 맞춰 고객이 가동 중지 시간을 피하고 줄이고 비즈니스에 가장 필요할 때 데이터와 애플리케이션을 사용할 수 있도록 보장할 것입니다. 회사는 지속적으로 솔루션을 최적화하여 고객에게 혜택을 줄 수 있는 추가 인접 서비스를 제공하고 애플리케이션 제공업체와 클라우드 제공업체가 효과적인 HA 전략을 수립하도록 지원할 것입니다.

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

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

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 보호 제품군입니다.

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

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

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

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