응용 프로그램 및 데이터베이스를 보호하는 방법 – SQL Server 클러스터링

SIOS로 SQL 클러스터링 솔루션의 미스터리 풀기

SQL Server 클러스터링은 LAN을 통해 연결된 둘 이상의 물리적 서버(노드) 모음을 설명하는 데 사용되는 용어로, 각각은 SQL Server 인스턴스를 호스팅하고 공유 저장소에 대해 동일한 액세스 권한을 가집니다. SQL 서버를 클러스터링하면 SQL Server 인스턴스를 호스팅하는 서버가 실패할 때마다 재해로부터 보호하고 고가용성을 제공합니다.

독립 실행형 서버에 있는 경우 하드웨어 오류로 인해 작업이 중단될 수 있습니다. 그러나 클러스터링을 사용하면 노드에 문제가 있는 경우 최소한의 가동 중지 시간으로 자동으로 다른 노드로 장애 조치할 수 있으며 IT가 문제를 해결하는 동안 사용자가 계속 작업할 수 있습니다. 기본 서버가 수정되면 신속하게 작업을 되돌릴 수 있습니다.

독립 실행형 서버를 사용하는 것과 비교할 때 SQL Server 클러스터링은 업그레이드 및 보안 패치를 적용할 때 가동 중지 시간을 제한할 수도 있습니다.

하는 동안 SQL 서버 클러스터링 제공 고가용성 시스템 가동 중지 시간을 최소화하지만 SQL Server 클러스터링은 서버 또는 응용 프로그램의 성능을 향상시키지 않습니다. 성능을 향상시키려면 서버의 컴퓨팅 성능을 업그레이드해야 합니다.

이 기사에서는 SIOS SQL Server 클러스터링 솔루션을 소개하고 SIOS와 Microsoft의 SQL 클러스터링 솔루션을 개략적으로 비교합니다.

SIOS SQL Server 클러스터링 솔루션

SIOS Technology Corp.는 인프라 및 애플리케이션 장애로부터 자동으로 복구하는 데 도움이 되는 고가용성 클러스터링 솔루션을 제공합니다. 지원하기 위해 SQL 서버 고가용성 , SIOS는 두 가지 솔루션을 제공합니다.

• SIOS DataKeeper 클러스터 에디션 Windows에서 실행되고 Microsoft WSFC(Windows Server 장애 조치 클러스터링)를 활용하여 공유 저장소(SAN) 또는 공유 저장소 없이(SANless) SQL Server 클러스터링을 제공합니다. SANless 환경은 단일 실패 지점을 제거하고 복제 효율성을 개선하며 SQL Server 이외의 응용 프로그램을 보호하고 분산 트랜잭션 및 시스템 데이터베이스를 보호합니다.
• Linux용 SIOS 보호 제품군 SAN 또는 SANless 환경에서 SQL Server를 비롯한 비즈니스 크리티컬 애플리케이션 및 데이터베이스를 보호하기 위해 장애 조치 클러스터링, 지속적인 애플리케이션 모니터링, 데이터 복제 및 구성 가능한 복구 정책이 긴밀하게 통합된 조합입니다.

각 솔루션의 기능과 이점을 자세히 살펴보겠습니다.

SIOS DataKeeper 클러스터 에디션

WSFC(Windows Server 장애 조치 클러스터링)는 고가용성을 향상시키는 Windows Server 플랫폼의 기능입니다. WSFC는 일반적으로 SQL Server를 사용하는 응용 프로그램에 고가용성을 제공하는 데 사용됩니다. 서버 또는 응용 프로그램 오류가 발생하는 경우 WSFC는 중복 컴퓨팅 리소스를 조정하고 대기 노드의 SQL Server 작업 및 데이터 복구를 자동으로 관리합니다. 안타깝게도 클라우드에서 SQL Server 애플리케이션을 실행하려는 경우 사용할 수 있는 SAN이 없습니다.

SIOS DataKeeper Cluster Edition을 사용하면 SANless WSFC를 쉽게 생성하여 클라우드, VMware 또는 Hyper-V와 같은 가상화된 환경 또는 로컬 스토리지만 사용하는 물리적 서버에서 작동하는 SQL Server 애플리케이션에 대한 고가용성 및 재해 복구를 달성할 수 있습니다.WSFC가 소프트웨어 클러스터를 관리하는 동안 SIOS 클러스터 소프트웨어는 실시간(동기 또는 비동기) 블록 수준 복제를 사용하여 로컬 스토리지를 동기화합니다. 동기화된 저장소는 WSFC에 기존 SAN 기반 저장소로 나타납니다. 온프레미스 데이터 센터와 클라우드 간의 재해 복구 보호를 위해 하이브리드 클라우드 구성을 구축할 수도 있습니다.

SIOS DataKeeper Cluster Edition 소프트웨어는 Microsoft의 완전 인증을 받았으며 클라우드 지역 및 영역의 모든 구성에서 엔터프라이즈급 가용성으로 작동합니다.

SIOS SANless 클러스터는 SAN의 비용, 복잡성 및 단일 장애 지점 위험을 제거할 뿐만 아니라 최신 고속 PCIe 플래시 및 SSD 스토리지를 사용하여 단일 비용 효율적인 솔루션에서 성능 및 보호를 사용할 수 있습니다.

Linux용 SIOS 보호 제품군

Linux용 SIOS 보호 제품군에는 다음이 포함됩니다.

• 전체 애플리케이션 스택을 모니터링하는 유연한 장애 조치 클러스터링 소프트웨어를 제공하는 SIOS LifeKeeper; 모범 사례에 따라 SQL Server 애플리케이션의 장애 조치를 오케스트레이션합니다.
• SANless 클러스터 구성에서 로컬 스토리지를 미러링하거나 재해 복구를 위해 원격 위치 또는 클라우드로 복제하기 위해 빠르고 효율적인 호스트 기반 블록 수준 데이터 복제를 제공하는 SIOS DataKeeper
• 다운타임 및 재해로부터 비즈니스 크리티컬 애플리케이션 및 데이터를 보호하기 위해 자동화된 구성 및 검증과 함께 애플리케이션 인텔리전스를 제공하는 다중 애플리케이션 복구 키트(ARK).

SIOS Protection Suite는 기존 HA 하드웨어 기반 클러스터를 지원하기 위해 SAN 환경에서 작동할 수 있지만 SANless를 실행할 수 있도록 서버 클러스터링에 대한 비공유 접근 방식을 만드는 데 사용할 수도 있습니다. 다양한 애플리케이션을 위한 자동 및 수동 장애 조치/장애 복구 복구 정책을 통해 강력하고 다양하며 쉽게 구성할 수 있는 솔루션을 제공합니다.

SIOS 대 Microsoft SQL 클러스터링 솔루션

시중에는 다른 SQL Server 클러스터링 솔루션이 있습니다. 가장 널리 사용되는 SQL Server 클러스터링 솔루션 중 일부는 Microsoft에서 제공하며 다음을 포함합니다.

• SQL Server 기본 가용성 그룹
• SQL Server Always On 가용성 그룹
• 공유 저장소가 있는 SQL Server 장애 조치(Failover) 클러스터 인스턴스

SQL Server 기본 가용성 그룹은 Windows에서 실행되며 최대 2노드 클러스터를 지원합니다. 데이터베이스 미러링 솔루션처럼 작동합니다. 클러스터링과 미러링은 모두 고가용성을 향상시키는 방법이지만 미러링은 데이터베이스 장애 조치만 허용합니다. 장애 조치(failover) 후에 필요한 SQL 외부의 다른 서비스, 파일 및 기타 리소스가 있거나 함께 유지해야 하는 여러 데이터베이스가 있는 경우 클러스터링이 더 나은 솔루션입니다.

SQL Server Always On 가용성 그룹은 Windows와 Linux 모두에서 실행되며 Microsoft에 따르면 "데이터베이스 미러링에 대한 엔터프라이즈 수준의 대안을 제공합니다."^[1] 값비싼 SQL Server Enterprise Edition이 필요합니다.

SIOS의 SQL 클러스터링 솔루션과 함께 SQL Server Standard Edition을 사용하면 소프트웨어 라이선스 비용을 최대 70% 절감하고 엔터프라이즈급 클러스터링 기능을 사용할 수 있습니다.

공유 저장소가 있는 SQL Server 장애 조치(Failover) 클러스터 인스턴스는 Windows와 Linux 모두에서 실행됩니다. 단일 사이트 솔루션이며 SAN이 필요합니다.

안타깝게도 SAN은 구입 및 유지 관리 비용이 비싸고 SAN 관리 전문 지식이 필요하며 단일 장애 지점입니다. SAN은 또한 데이터베이스 성능에 부정적인 영향을 줄 수 있습니다.

SQL Server Always On, SQL Server Failover Cluster 및 SIOS DataKeeper Cluster Edition의 강점과 약점에 대한 보다 자세한 비교를 찾을 수 있습니다. 여기 .

클라우드의 SQL Server 클러스터링

Linux용 SIOS DataKeeper 및 SIOS Protection Suite는 고가용성 및 재해 복구 물리적, 가상, 클라우드 또는 하이브리드 클라우드 인프라의 모든 조합에서 작동하는 Windows 및 Linux 애플리케이션을 각각 보호합니다. 예를 들어 SIOS DataKeeper는 다음을 수행할 수 있습니다.

• SQL Server를 비롯한 중요한 온프레미스 또는 하이브리드 비즈니스 애플리케이션을 AWS, Azure 또는 Google Cloud의 고가용성 Windows 또는 Linux 환경으로 보호합니다.
• AWS, Azure 또는 Google Cloud에서 Windows 또는 Linux 클러스터를 생성하여 SQL Server 클라우드 애플리케이션을 보호하십시오.
• 클라우드 가용성 영역 또는 지역에서 SQL Server 인스턴스를 장애 조치하여 사이트 전체, 로컬 또는 지역 고가용성 및 재해 복구 보호를 제공합니다.

SIOS DataKeeper Cluster Edition 및 Linux용 SIOS Protection Suite는 모두 클러스터된 공유 스토리지를 시뮬레이션하고 클라우드 지역 및 가용성 영역에서 완전히 인증된 고가용성 클러스터 보호를 제공할 수 있습니다.

마지막 생각들

SIOS는 광범위한 애플리케이션, 운영 체제 및 인프라 환경을 지원하는 제품을 제공하여 모든 고가용성 요구 사항을 처리할 수 있는 단일 솔루션을 제공합니다. 다음은 SIOS의 힘을 보여주는 몇 가지 예입니다.

• 페이고( paygoutilities.com ) AWS에서 SQL Server의 고가용성을 제공하기 위해 WSFC와 함께 SIOS DataKeeper를 구현했습니다.
• 의료 정보 서비스 제공업체는 SIOS DataKeeper를 사용하여 18개 이상의 클러스터 노드에서 중요한 SQL Server를 보호하고 대역폭 문제를 제거하고 데이터 보호를 개선하며 중요한 의료 네트워크 환경에서 가동 중지 시간을 줄입니다.
• Mavis Discount Tire는 SIOS DataKeeper Cluster Edition을 사용하여 비즈니스에 중요한 SQL Server에 고가용성을 제공합니다.

Windows 또는 Linux 환경에서 SQL Server를 보호하기 위한 고가용성/재해 복구 솔루션을 찾고 계시다면, 여기에서 더 많은 정보를 찾을 수 있습니다 .

SQL Server 고가용성 및 재해 복구에 대한 블로그 게시물 보기 .

참고문헌 https://www.mssqltips.com/sqlservertip/1541/getting-started-with-sql-server-clustering/ https://www.brentozar.com/archive/2012/02/introduction-sql-server-clusters/^[1] https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server?view=sql-server-ver15 의 허가를 받아 재생산 시오스

비즈니스 연속성 계획이 필요한 이유

FaceBook, Instagram 및 WhatsApp은 정말 나쁜 월요일을 보냈습니다.

여기 동부 해안에서 근무 시간이 끝나고 Facebook을 여전히 사용할 수 없다는 것을 알았습니다. Facebook은 다음 두 트윗에서 문제를 인정했습니다.

다운타임의 정확한 원인과 사용자 오류인지, 악의적인 공격인지, 아니면 예상치 못한 오류의 재앙인지는 알 수 없지만 이 시점에서 이 중단에 대해 몇 가지를 알 수 있습니다.

가동 중지 시간이 비쌉니다

오늘날 경험하는 가동 중지 시간의 정확한 비용은 결코 알 수 없지만 이미 측정할 수 있는 몇 가지 비용이 있습니다. 이 글을 쓰는 시점에서 페이스북 주가는 오늘 4.89% 하락했다. 이는 페이스북과 기타 기술주에 이미 잔인한 9월을 넘어선 것입니다.

그러나 회사의 실제 비용은 얼마였습니까? 많은 브랜드가 소셜 미디어를 마케팅 활동의 중요한 부분으로 활용하고 있는 상황에서 이러한 중단이 향후 광고 지출에 어떤 영향을 미칠까요? 최소한 광고주가 다른 소셜 미디어 플랫폼을 아직 조사하지 않은 경우 조사할 것으로 예상합니다. 시간이 지나야 알 수 있지만 이 중단 이전에도 다음과 같은 다른 플랫폼에서 마케팅 비용에 대한 더 많은 경쟁이 발생했습니다. 틱톡 .

최악의 시나리오에 대한 계획

상황이 발생하면 우리는 그것을 알고 그에 대한 계획을 세웁니다. 비즈니스 연속성 계획 (BCP)는 다음 주소로 작성되어야 합니다. 어느 가능한 재난. 다시 말하지만, 우리는 이 특정 재난의 정확한 원인을 알지 못하지만 5시간 이상의 RTO가 Facebook, Instagram 또는 WhatsApp의 선반에 있는 BCP에 기록되지 않았다는 것을 이미징해야 할 것입니다.

귀하의 BCP에는 무엇이 있습니까? 혹시 모를 재난을 상상해 보셨습니까? 다운타임의 영향을 측정하고 비즈니스의 각 구성 요소에 대해 적절한 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)를 정의했습니까? 잘못될 수 있는 모든 가능한 일에 대해 계획하는 것은 불가능하다고 감히 말씀드리고 싶습니다. 그러나 모든 사람에게 정기적으로 BCP를 다시 방문하고 마지막으로 BCP를 검토했을 때 레이더에 포착되지 않았을 수 있는 재해를 포함하도록 업데이트하도록 조언합니다. BCP에 세계적 대유행이 있었습니까? 그렇지 않은 경우 "재택 근무" 인력을 수용하기 위해 분주하게 움직였을 수 있습니다. 요점은 최악의 상황에 대비하고 최선을 다하는 것입니다.

재난 시 통신

재해 발생 시 통신은 BCP에서 자체 챕터여야 합니다.

한 Facebook 직원은 Reuters에 모든 내부 도구가 다운되었다고 말했습니다. 이 문제를 추적하는 사람들은 직원들이 폐쇄로 인해 자신의 도구 중 일부에 액세스할 수 없었기 때문에 Facebook의 대응이 훨씬 더 어려워졌다고 말했습니다.

여러 직원이 무엇이 잘못되었는지 듣지 못했다고 말했습니다.

https://www.reuters.com/technology/facebook-instagram-down-thousands-users-downdetectorcom-2021-10-04/

진정으로 강력한 BCP에는 여러 대체 통신 수단이 포함되어야 합니다. 귀하의 비즈니스가 여러 건물, 지역 또는 국가에 걸쳐 확장됨에 따라 이는 훨씬 더 중요해집니다. 오늘 팀이 의사 소통하는 방식에 대해 생각해보십시오. 전화, 문자, 이메일, Slack이 상위 4개일 수 있습니다. 그러나 모두 사용할 수 없다면 어떻게 팀에 연락할 수 있습니까? 모르는 경우 다른 옵션을 조사하는 것이 좋습니다. 단파 라디오와 운반비둘기 떼가 필요하지 않을 수도 있지만 "비상 시 유리를 깨는" 상황에 대비하여 이 두 가지를 모두 보유하고 있는 정부 기관이 있다고 확신합니다.

요약

귀하는 귀하 자신, 귀하의 고객 및 투자자에 대해 귀하의 비즈니스 가용성과 관련된 모든 예방 조치를 취해야 할 책임이 있습니다. BCP를 생성하는 데 적절한 리소스를 투자하고 비즈니스 연속성을 담당하는 팀이 BCP에 정의된 RTO 및 RPO를 충족하는 데 필요한 도구를 보유하고 있는지 확인하십시오.

클라우드 여정 수정

어떤 식으로든 2020년과 2021년의 세계를 변화시키는 사건은 우리가 알고 있던 거의 모든 것을 재편성했으며 고가용성도 예외는 아닙니다. 폐쇄 및 제한에도 불구하고 많은 IT 팀은 온프레미스 데이터 센터를 클라우드로 전환했습니다.많은 사람들이 '이제 어떻게 합니까?'라고 묻습니다. 다음은 2022년 클라우드 여정을 수정하기 위해 해야 할 5가지 사항입니다.

1. 추가하다 고가용성

   클라우드로의 전환 과정에서 많은 IT 및 비즈니스 리더는 COVID-19로 인해 폐쇄된 데이터 센터에서 클라우드로 서비스와 애플리케이션을 이동하기 위해 서두르고 있음을 알게 되었습니다. 다른 사람들은 데이터 센터 폐쇄 때문이 아니라 폭발적인 수요에 대처하기 위해 클라우드로 돌진했습니다. 일부의 경우 클라우드로의 여정이 너무 빨라서 HA가 포함되지 않았습니다. 이제 그들은 애플리케이션이 여전히 클라우드에서 충돌하고 예기치 않은 중단과 계획되지 않은 다운타임이 여전히 AWS, Azure 및 GCP는 이전 데이터 센터에 있던 것과 동일합니다.

   클라우드 여정을 수정하는 첫 번째 단계는 씨 . 이는 기업에 다음과 같은 몇 가지 의미가 있습니다.

   • 고가용성 중복 아키텍처 설계 및 설계
   • 중요한 구성 요소 및 응용 프로그램을 보호할 소프트웨어 및 서비스 선택
   • 관련 프로세스 및 절차, 최소한의 거버넌스 정의 및 문서화
   • 품질 보증, 절차 테스트 및 혼돈 테스트를 위한 프로덕션 사본 배포

2. 재해 복구를 위한 더 높은 가용성을 위해 확장

   물론 모든 사람이 어떤 형태의 HA를 고려하지 않고 클라우드로 전환한 것은 아닙니다. 일부 IT 팀은 HA를 온프레미스로 두지 않을 것을 예견했지만 클라우드로 급하게 이동하면서 중요한 모든 서버를 동일한 클라우드 가용 영역으로 옮겼습니다. 완전한 취약성보다 일부 HA 보호 기능이 있는 것이 좋지만 단일 가용 영역(AZ)에만 서버와 애플리케이션을 배포했다면 이제 대기 클러스터 노드에 대해 다중 AZ로 확장하거나 구축할 때입니다. 다른 지역에 세 번째 노드를 배포하여 재해 복구. SIOS'는 수십 명의 고객이 다중 AZ 아키텍처를 계획하고 재해 복구 솔루션을 추가하도록 도왔습니다.

3. 팀 구축

   하룻밤 사이에 일부 회사와 IT 팀은 완전한 온프레미스에서 Cloud Formation 템플릿, 빠른 시작 가이드, IAM 역할, 내부 로드 밸런서, 오버레이 IP와 씨름하고 VM 크기가 정확히 무엇을 의미하는지 해독하기 위해 노력했습니다.이제 클라우드로의 여정을 지원할 팀을 구성할 때입니다.이것은 여러 가지를 의미합니다:

   • 용량 추가.완전한 리프트 앤 시프트를 수행할 수 없다면 클라우드 및 온프레미스 애플리케이션을 관리하는 동일한 직원이 있을 것입니다.레거시 솔루션은 변덕스럽고 안정적이고 가용성을 유지하기 위해 많은 작업이 필요한 것으로 알려져 있습니다. 클라우드 여정을 앞서 탐색하려면 가용성 요구 사항을 해결하고 클라우드 아키텍처를 이해하며 엔터프라이즈 요구 사항에 맞게 앞으로의 과정을 계획할 수 있는 용량이 필요합니다.
   • 훈련을 통해 기술을 강화합니다.클라우드에 대한 팀 교육을 제공합니다.향후 과정을 관리하고 계획하려면 클라우드 솔루션, 아키텍처, 모범 사례 및 장단점에 대한 추가 교육을 통해 조직 내에서 IT 우수성을 강화할 방법을 찾으십시오.자신있게 훈련된 직원은 가용성 증가로 배당금을 지급할 뿐만 아니라 경제적이고 확장 가능하며 논리적인 방식으로 가용성, 유지 관리 및 성장을 해결함으로써 배당금을 지급할 것입니다.번역: 나머지 클라우드 인프라를 구축할 때 비용 낭비를 방지합니다.

4. 자동화 및 분석 통합

   SIOS Technology Corp의 고객 경험 부사장 저는 HA, DR 또는 해당 팀을 희생하지 않고 2021년에 클라우드로 전환한 여러 회사와 협력했습니다.필요한 가동 시간 수(99.99%)를 달성하는 것을 진지하게 생각하고 재해 계획을 수립하는 것이 협상할 수 없는 경우 엄격한 분석 및 추가 모니터링을 추가해야 할 때입니다. 가용성 솔루션에 재해 또는 계획되지 않은 다운타임 발생 시 복구를 위한 애플리케이션 인식 자동화 및 오케스트레이션이 있는지 확인합니다. 분석 및 자동화를 추가하여 솔루션을 강화하고 클라우드 마이그레이션을 사후 장애 조치 중 하나에서 사전 예방 알림 및 오류가 발생하기 전에 완화에 이르기까지 한 단계 업그레이드하십시오.성능이 저하된 애플리케이션이나 증가하는 대기 시간, 오류 또는 VM 무응답 동작에 대한 알림을 제때 수신하여 비즈니스 피크 시간에 다운타임을 방지한다고 상상해 보십시오. 분석은 원래 가용성 아키텍처에서 벗어날 수 있는 시스템과 애플리케이션을 드러낼 수 있기 때문에 중요합니다.

5. 프로세스 및 거버넌스 업데이트

   우리가 실패라고 생각하는 많은 것들이 프로세스의 실패에 뿌리를 두고 있습니다. 조직의 프로세스가 최신 상태이고 잘 문서화되어 있으며 적절하게 전달되고 준수되는지 확인하십시오. 이러한 프로세스에는 누가, 무엇을, 언제, 어디서, 어떻게 모두가 고객과 관련된 비즈니스 전략, 목표 및 조직 요구와 연결되는지와 관련된 몇 가지 핵심 최소값이 포함되어야 합니다.

   새 클라우드 환경에 대한 소유권 및 승인 프로세스가 문서화되어 있는지 확인하십시오. 인프라를 확보하는 하드웨어 팀에서 클라우드 팀으로 이동한 고객의 역할과 책임이 상충하거나 충돌하거나 해결되지 않아 발생하는 좌절감을 직접 목격했습니다. 마이그레이션을 통한 혼란은 일련의 고충 중 하나이며 명확한 거버넌스 없이 재해를 파헤치는 것은 훨씬 더 크고 비용이 많이 드는 문제입니다.

   클라우드로 도약했다면 거기에 머물면서 클라우드를 작동하게 만드는 것이 여정의 다음 부분입니다.클라우드 여정이 갑작스럽거나 불안정한 경우 클라우드 여정을 수정하기 위해 다음 5가지 사항을 고려하고 SIOS 기술이 클라우드에서의 고가용성뿐만 아니라 클라우드에서 실행하기 위한 프로세스를 개선하는 데 도움이 될 수 있음을 알아두십시오.

의 허가를 받아 재생산 시오스

SIOS DataKeeper Cluster Edition 라이센스 키를 설치하는 방법

일단 설치하면 SIOS DataKeeper 클러스터 에디션 소프트웨어 라이선스를 활성화한 경우 시작하기 전에 라이선스 키를 설치해야 합니다. 이 4분짜리 비디오는 SIOS DataKeeper Cluster Edition 소프트웨어를 설치하는 방법을 검토하고 중요한 애플리케이션 보호를 시작하기 위해 라이선스를 활성화하는 방법을 보여줍니다.

SIOS 지원 담당자가 SIOS 라이선스를 설치하는 데 필요한 세 가지 주요 전제 조건 각각을 시연하는 것을 시청하세요. 간단한 라이선스 키 관리자를 사용하여 활성화된 라이선스 구입한 권한에서 라이센스 키를 다운로드 및 적용하고 SIOS DataKeeper 소프트웨어 .

이 비디오는 또한 우리의 액세스 프로세스를 안내합니다 SIOS 문서 포털 , 릴리스 정보, 설치 가이드, 기술 문서 및 SIOS DataKeeper Cluster Edition을 자세히 설명하는 정보는 물론 SIOS에 대한 광범위한 주제를 찾을 수 있습니다.

단계를 빠르고 간단하게 완료하는 방법에 대한 팁과 편리한 통찰력을 보십시오.이제 SIOS DataKeeper 클러스터링 소프트웨어로 중요한 애플리케이션을 보호하기 시작합니다.

 

클러스터 복원력, 성능 및 결과를 개선하기 위한 4가지 회피 전략

SIOS Protection Suite 클러스터 환경에서 배포를 위한 간단한 단계

무언가를 피하는 것 – 우리는 모두 전에 그것을 해왔습니다.우리가 배우자와 함께 걸을 때 가게에서 볼 수 있는 오래된 불꽃, 우리가 "살 준비가 되지 않았을 때" 판매원, 그리고 우리가 "휴가"에 있는 동안 상사조차도.내가 개발팀장이었을 때, 나는 부하직원들이 아파서 사무실에 없을 때 매장을 둘러보는 것을 얼핏 보았다.그들은 옷걸이 사이로 몸을 숨기고 서둘러 옆 통로를 따라 달려갔다.우리 모두는 전에 그것을 해왔고 어떤 경우에는 정신 건강, 신체 건강 또는 사적이고 개인적인 이유로 인해 모두 회피 조치가 필요합니다.HA에서도.그렇다면 고가용성 환경에 회피 기능을 추가하는 방법과 그 이유는 무엇입니까?

고가용성에서 회피 전략을 사용하는 4가지 이유

1. 더 나은 성능 (서버 과부하 최소화)

HA에서 회피 전략을 사용하는 한 가지 이유는 응용 프로그램 및 서버 성능을 높이는 것입니다.프로덕션 워크로드를 실행하는 세 대의 서버의 경우를 생각해 보십시오. 이를 Server Alpha, Server Beta, Server Gamma라고 부르겠습니다.서버 알파 및 베타는 데이터베이스로 지원되는 중요한 애플리케이션을 실행하는 반면 서버 감마는 보고서 및 데이터 변환 작업을 실행합니다.서버 알파에 장애가 발생하면 서버 베타로의 장애 조치가 일반적으로 발생합니다.그러나 베타 서버는 이미 큰 작업 부하를 실행하고 있기 때문에 추가 응용 프로그램 로드로 인해 바람직하지 않은 서버 과부하가 발생하고 두 응용 프로그램의 성능이 저하될 수 있습니다.따라서 서버 감마가 장애 조치 대상으로 선택되었는지 확인하기 위해 회피 전략을 배포하는 것이 현명할 수 있습니다.

2. 성능 최적화

Alpha, Beta 및 Gamma의 세 서버 시나리오를 다시 고려하십시오.서버 알파 및 베타는 최대 워크로드를 처리하도록 확장되는 반면 Server Gamma는 비용 최적화된 서버입니다.서버 알파 및 서버 베타에 장애가 발생하면 비용 최적화 서버인 Gamma로 장애 조치가 발생합니다.그러나 이 서버는 최대 작업 부하나 서버 알파와 서버 베타의 작업 부하를 동시에 처리하도록 확장되지 않습니다.이 경우 회피 전략을 사용하여 다른 호스트를 사용할 수 있게 되는 즉시 Server Gamma에서 워크로드 중 하나 또는 둘 다를 자동으로 이동하여 성능을 최적화할 수 있습니다.

3. 고가용성 최적화

HA 최적화는 회피 전략을 배포하기 위한 또 다른 시나리오입니다. 성능 최적화 전략과 마찬가지로 HA 최적화는 환경이 대부분의 실패 시나리오에서 살아남을 수 있도록 하고 애플리케이션이 어느 시점에서든 가능한 최고 수준의 가용성을 제공하도록 최적화되어 있는지 확인하는 데 사용됩니다.HA 최적화는 인큐 프로세스가 복제된 SAP와 같은 애플리케이션에 중요합니다.모든 SAP 환경에서 잠금 손실 및 취소된 작업의 위험 때문에 ASCS(ABAP SAP Central Service) 및 ERS(복제 대기열 삽입) 인스턴스가 동일한 서버에 장기간 상주하는 것을 원하지 않습니다. 이를 방지하기 위해 ERS 및 ASCS 인스턴스가 항상 반대 클러스터 노드에서 실행되도록 하는 회피 전략을 사용할 수 있습니다.프로덕션 워크로드를 실행하는 세 대의 서버의 경우를 고려하여 서버 알파, 베타, 감마라고 합시다.서버 알파는 ASCS 인스턴스를 실행하고 서버 베타는 ERS 인스턴스를 실행합니다.Server Gamma는 ERS(Server Beta)와 ASCS(Server Alpha)의 장애 조치를 위한 세 번째 노드 역할을 합니다.베타가 충돌하는 경우 ASCS 인스턴스와 동일한 노드에서 실행되는 ERS 리소스를 원하지 않을 것입니다.이 작업을 보장하기 위해 먼저 자동으로 확인하고 두 애플리케이션이 별도의 서버에 있는지 확인하고 잠금 장애 조치를 위한 SAP ASCS/ERS 모범 사례를 유지 관리하는 회피 전략을 배포할 수 있습니다.

4. DR 회피

약 70마일 떨어진 City Alpha와 City Beta의 두 데이터 센터가 있고 대부분의 클라이언트가 그 사이에 있다고 가정합니다. 그러나 최근 내부 조직, 합병/폐쇄 및 인수, 거버넌스 요구 사항의 변경으로 인해 IT 팀은 Alpha 및 Beta에서 약 350마일 떨어진 City Gamma에 위치한 세 번째 데이터 센터를 추가해야 합니다.이제 알파 및 베타에서 주로 보호되었던 리소스도 감마 위치로 확장됩니다.대부분의 사용자와 팀이 알파 및 베타 위치 근처에 있고 가장 극단적인 사용자도 이웃 도시에 있다는 점을 감안할 때 팀은 감마 위치로의 장애 조치를 피해야 합니다. 다른 전략과 마찬가지로 DR 회피는 한 지역 내에서 하나의 노드만 실패할 경우 DR 노드를 방지하여 성능, 내부/외 지역 데이터 비용, 대기 시간 및 클라이언트 액세스를 최적화하려고 합니다.또한 두 노드가 서로 다른 시간 후에 실패하더라도 DR로 이동하기 전에 항상 클러스터 또는 데이터 센터의 다른 노드로 장애 조치가 발생하도록 합니다. 그렇다면 회피 전략을 어떻게 전개할 것인가?많은 공급자가 구성할 수 있는 선호도 규칙을 가지고 있는 반면 다른 공급자는 서버 우선 순위 또는 수동 단계의 조합을 사용합니다.Linux용 SIOS Protection Suite의 경우 다음을 포함한 여러 기본 제공 방법을 사용할 수 있습니다.

1. 리소스 우선 순위 지정

장애가 발생하면 리소스는 남아 있는 우선 순위가 가장 낮은 서버로 장애 조치되고 추가 서버(알파, 베타 및 감마)로 캐스케이드됩니다.Server Alpha는 Resource.HR의 기본 서버이고, Server Beta는 Resource.MFG의 기본 서버이며, Server Gamma는 모든 리소스/서버의 백업 서버입니다.리소스 우선 순위 지정을 사용하면 Resource.HR은 Server Alpha에서 1의 우선 순위를 가지며 Server Gamma에서 2의 우선 순위를 갖습니다.Resource.MFG는 Server Beta에서 1의 우선순위를 가질 수 있고 Server Gamma에서 2의 우선순위를 가질 수 있습니다.고객이 환경 사용을 최적화하려는 경우 Resource.HR은 Server Beta에서 3의 우선 순위를 가질 수 있고 Resource.MFG는 Server Alpha에서 3의 우선 순위를 가질 수 있습니다.Server Alpha에 오류가 발생하는 경우 Resource.HR 리소스는 Server Alpha에서 서비스 시작(복원)을 시도하기 전에 먼저 Server Gamma에 실패합니다.

Linux용 SIOS Protection Suite(UI 및 CLI)를 사용하면 사용자가 각 서버 및 리소스 조합에 대한 우선 순위를 지정할 수 있습니다.

2. 정책 또는 선호도 규칙

또한 정책 규칙을 사용하여 지정된 서버에서 리소스 복구가 발생하지 않도록 함으로써 리소스가 더 중요하거나 리소스 집약적인 작업 부하를 실행할 수 있는 지정된 서버를 피할 수 있습니다.일반적인 정책은 다음과 같습니다.

• • • • • • 기본적으로 특정 서버의 애플리케이션을 차단하는 제약 조건 정책입니다.
          • 리소스가 충분하지 않은 서버에서 애플리케이션을 차단하는 리소스 정책
          • 리소스가 시스템에서 허용되거나 허용되지 않는 기간을 정의하는 임시 정책
          • 클러스터 내에서 선호하는 서버 또는 가능한 애플리케이션 소유권 기능을 정의하는 사용자 정의 정책.

SIOS Protection for Linux CLI를 사용하면 지정된 서버의 특정 리소스에 대한 장애 조치를 비활성화하고, 오류를 보호하는 임시 정책을 제공하고, 특정 애플리케이션 유형, 제약 조건 정책 및 사용자 지정 정책의 오류를 비활성화할 수 있는 정책 규칙을 지정할 수 있습니다.

• 특정 회피 리소스

자원 회피 전략을 수립하는 가장 세부적인 방법은 각 계층 내에 특정 회피 스크립트를 배포하는 것입니다.이 방법을 사용하면 사용자가 특정 응용 프로그램(예: app1 및 app2)을 구성하여 가능한 한 서로를 피하면서 다른 응용 프로그램이 제한 없이 실행되도록 할 수 있습니다.Alpha, Beta 및 Gamma의 세 서버와 app1, app2 및 app3의 세 리소스의 경우 이 방법이 가장 큰 유연성을 제공합니다.이 예에서 app1과 app2는 서버가 실패할 때 배열을 피하려고 하지만 app3은 배열 제한 없이 우선 순위에 따라 사용 가능한 다음 노드로 실패합니다.

회피 전략 및 리소스의 추가 예를 보려면 Linux용 SIOS Protection Suite를 고려하십시오. 선적 서류 비치 .고객이 가능하면 다른 노드에서 실행해야 하는 두 개의 애플리케이션(app1 및 app2)이 있는 경우 고객은 Linux gen/app 리소스용 SIOS Protection Suite와 '/opt/LifeKeeper'를 사용하여 두 개의 회피 터미널 리프 노드 리소스를 생성할 수 있습니다. /lkadm/bin/avoid_restore' 스크립트.

– Cassius Rhue, VP, 고객 경험

에서 재생산 시오스