내 서버는 일회용인가요? 고가용성 소프트웨어가 클라우드 모범 사례에 어떻게 적용되는가?

~ 안에이것VMblog 기사 “내 서버는 일회용인가? 고가용성 소프트웨어는 클라우드 모범 사례에 어떻게 적용되는가”에서 SIOS Technology의 소프트웨어 엔지니어인 필립 메리는 클라우드 컴퓨팅으로의 전환이 현대 IT 환경에서 서버의 역할과 인식을 어떻게 변화시켰는지 살펴봅니다. 자동화와 코드형 인프라(IaC)의 등장으로 서버는 점점 더 일회용이 되고, 쉽게 생성, 폐기, 교체할 수 있게 되었으며, 이는 AWS Well-Architected Framework에 제시된 클라우드 모범 사례와 일치합니다. 메리는 인프라는 일시적인 것으로 간주될 수 있지만, 인프라에서 실행되는 애플리케이션은 여전히 ​​중요하며 지속적으로 가용성을 유지해야 한다고 강조합니다. 이러한 간극을 메우기 위해 고가용성(HA) 소프트웨어는 IT 팀이 애플리케이션 연속성을 기반 서버 하드웨어와 분리하여 가동 시간과 안정성을 유지할 수 있도록 하는 중요한 역할을 합니다. 이러한 접근 방식을 통해 조직은 필수 애플리케이션의 안정성과 성능을 저하시키지 않고 클라우드 환경의 유연성을 활용할 수 있습니다.

저자: Beth Winkowski, SIOS Technology Corp. 홍보 담당

허가를 받아 재생산되었습니다.시오스

 

재난에 취약한 세상을 위한 데이터 복구 전략

소프트웨어 엔지니어링, 시스템 관리, 그리고 고객 지원 분야에서 일하는 것은 다양한 구성과 수많은 문제를 직접 경험할 수 있는 특별한 기회입니다. 또한, 이러한 직책은 순수 엔지니어링 분야에서는 접하기 어려운 방식으로 사용자의 다양한 요구, 어려움, 그리고 우려 사항에 대한 관점을 제공합니다.

지원팀에서 거의 5년 동안 일하면서 함께 일했던 다양한 팀에서 나타나는 패턴을 발견했습니다. 또한, 다양한 구성에 대한 지원을 요청받았을 때 다양한 사용 사례와 근본 원인 간의 유사점을 찾을 수 있는 특별한 기회를 얻었습니다. 따라서 새로운 팀과 협업을 시작할 때 반드시 확립해야 할 기반이 있습니다. 이 기반을 구축한다는 것은 관리 관행을 통해 HA/DR 제품군을 최적으로 활용하고, 팀이 고가용성을 설계하는 방법을 알고, 시스템 소프트웨어 외의 유틸리티를 활용하여 성공을 달성하는 방법을 이해하도록 하는 것을 의미합니다. 이 기반은 팀이 운영 기준을 충족하거나 초과 달성하는 방법을 아는 데 매우 중요할 수 있습니다. 요약하자면,일반적인 질문그리고 이 답변은 구현에 관심이 있지만 새로운 사람들을 위한 리소스로 활용됩니다.고가용성 솔루션또는 단순히 새로운 고가용성 솔루션으로 전환하고 싶을 수도 있습니다. 시스템 관리/시스템 엔지니어링을 이제 막 공부하기 시작한 학생이든, 시스템 아키텍처 계획까지 업무 범위를 확장해 달라는 요청을 받은 베테랑 소프트웨어 엔지니어이든, 아래 내용은 고가용성/재해 복구 제품군을 최대한 활용하는 데 도움이 될 수 있습니다.

더 이상 미루지 않고, 아래 질문은 내 역할에서 본 일반적인 대화 주제를 요약한 것이며, 핵심 개념을 이해하고 적합한 솔루션을 찾는 데 도움이 될 것입니다.

재해 복구란 무엇이고, 어떤 작업을 수반합니까?

재해 복구, 와 결합하면고가용성, 복구 시간 목표(RTO) – 서비스가 복구되기 전까지 액세스할 수 없는 기간 – 및 복구 지점 목표(RPO) – 백업에서 복원할 때 손실될 수 있는 데이터 – 를 최적화하기 위해 작동합니다.복구 시간 목표시스템이 다운되어도 운영 기준을 충족할 수 있는 시간을 나타냅니다. 일반적으로 이 지표는 백분율로 표현됩니다. 일반적인 “5 nines of uptime”은 99.999%의 가동 시간 또는 연간 최대 5분의 가동 중지 시간을 나타냅니다. 복구 지점 목표는 조금 더 복잡하며 운영 기준을 충족하면서 손실될 수 있는 데이터 양을 나타냅니다. 예를 들어, 재해 발생 시 시스템이 데이터를 전혀 잃지 않으면 “제로 RPO”라고 합니다. 시스템이 타임라인에 존재한다고 생각하고 복구 지점 목표를 다음 질문에 대한 답으로 생각하면 도움이 될 수 있습니다. “시스템에 재해가 발생하면 시스템 타임라인에서 얼마나 뒤로 ‘되돌려’ 운영 기준을 충족할 수 있습니까?”

재해 복구는 정전을 견뎌내는 기존 접근 방식과 어떻게 다릅니까?

전통적으로 고가용성 인프라가 없는 재해 발생 환경은 복구 시간 목표가 길 수 있습니다. 시스템을 복구하고, 문제를 해결하고, 관리자가 애플리케이션을 시작해야 할 수도 있습니다. 문제의 심각도에 따라 복구 및 운영에 몇 시간 이상 걸릴 수 있습니다. 팀은 효율적으로 작업하고 긴밀한 소통을 통해 실수 없이 서비스를 복구해야 하며, 그렇지 않으면 운영 재개에 추가적인 지연이 발생할 위험이 있습니다. 또한, 이러한 중단으로 인해 손실되는 데이터는 상당할 수 있습니다. 최근에 백업을 수행하지 않았거나 최신 데이터 사본에 액세스할 수 없는 경우, 팀은 “오래된” 데이터에 의존하게 되고 중요한 데이터 손실로 인해 조직 전체의 운영 차질을 겪을 수 있습니다. 고객 관점에서 생각해 보면, 필요할 때 온라인 서비스에 액세스하기 위해 얼마나 기다릴 의향이 있습니까? 고객으로서 온라인 매장에서 거래 기록이 손실되는 것을 얼마나 용납하시겠습니까?

고가용성 인프라, 스토리지 미러링 수단, 그리고 고가용성 오케스트레이션 수단을 도입하면 RTO와 RPO에 영향을 미치는 모든 요소가 최적화되어 재해 발생 시 훨씬 더 유연하게 대처할 수 있습니다. 고가용성 인프라는 이중화되어 있으므로 대기 시스템이 운영을 인계받을 수 있습니다. 또한, 클러스터 환경을 관리하는 소프트웨어인 오케스트레이터는 대기 시스템에서 수동 개입보다 훨씬 뛰어난 응답성, 안정성, 그리고 효율성을 바탕으로 서비스를 체계적으로 시작할 수 있습니다. 결과적으로 복구 시간 목표가 단축되어 재해 복구에 몇 시간이 걸리는 대신 단 몇 분 이내에 완료할 수 있습니다.

고가용성 인프라의 또 다른 측면은 데이터 중복성입니다. 디스크는 “미러링”될 수 있는데, 이는 서로 다른 시스템에 연결된 디스크들이 모두 실시간으로 정확히 동일한 데이터를 수신할 수 있도록 합니다. 결과적으로, 앞서 언급한 대기 시스템에서 사용 가능한 데이터는 정확한 사본이 될 수 있으며, 재해 발생 직전에 데이터 백업을 효과적으로 유지할 수 있습니다. 결과적으로, 서비스가 복구되면 애플리케이션은 거의 0에 가까운 복구 시점 목표(RPO)로 실행되어 오케스트레이터가 대기 시스템으로 작업을 이전할 때 복구 시점 목표를 가능한 가장 최신의 운영 상태로 유지합니다.

조직이 고가용성 재해 복구(HADR) 전략을 설계할 때 가장 흔히 저지르는 실수는 무엇이며, 이를 어떻게 피할 수 있습니까?

가장 흔히 관찰되는 실수 중 하나는 QA/테스트 환경의 부재입니다. SIOS 고객 경험 팀은 조직이 애플리케이션/운영 체제를 테스트하려는 이러한 사례에 여러 차례 대응했습니다.패치/업그레이드아니면 단순히 일상적인 유지 관리 및 계획 부족이나 어떤 종류의 안타까운 비호환성으로 인한 문제일 수도 있습니다.중단 시간환경에서 발생하는 문제이며, 유지 관리 절차가 복구 절차로 전환됩니다. 이로 인해 지연, 복잡성이 발생하고 운영 환경 내에서 문제가 악화될 가능성이 있습니다.

조직에 제공할 수 있는 가장 중요한 권고 사항은 품질 보증 기능을 갖춘 운영 환경의 일대일 복사본을 만드는 것입니다. 운영 환경에서 수행해야 하는 모든 절차는 먼저 QA 환경에서 “드레스 리허설”을 거쳐야 합니다. 이를 통해 조직은 계획된 운영을 자유롭게 수행하고 인프라의 생산성을 위험에 빠뜨리지 않고 개선할 수 있습니다. 안전하고 위험 부담이 적은 환경에서 운영을 연습하면 팀은 예상치 못한 문제 발생 위험 없이 운영 환경에서 신속하고 정확하게 대응하기 위해 “대본에서 벗어난” 상황에 처할 위험 없이 운영 환경을 운영할 수 있습니다. QA 환경에서 문제가 발생하면 지원팀에 연락하여 비즈니스 운영에 영향을 미치지 않도록 안전하게 문제를 조사할 수 있습니다. 이를 통해 통제되고 계획적이며 효과적인 방식으로 해결책을 찾아 운영에 구현할 수 있는 가능성이 크게 향상됩니다.

앞서 언급한 QA 환경의 이점은 모든 조직에 중요합니다. 하지만 조직이 더욱 복잡한 유지 관리 전략을 채택함에 따라 이러한 테스트 환경의 중요성은 더욱 커집니다. 이 테스트 환경을 활용하면 업그레이드 절차가 더욱 원활해질 뿐만 아니라, 유지 관리 활동 중 향상된 시스템 가용성을 확보하기 위해 복잡성을 유발하는 유지 관리 모델을 도입할 때 발생하는 위험을 완화할 수 있습니다. 어떤 경우든 QA 환경에서 유지 관리 계획을 테스트하고, “드레스 리허설” 결과를 기반으로 계획을 개선하고, 이러한 실무 경험을 활용함으로써 조직은 문제 발생 위험을 최소화하면서 운영 시스템을 관리할 수 있습니다.

단일 실패점을 제거하는 것이 왜 중요한가요?

팀이 경험할 수 있는 또 다른 일반적인 장애물은 아키텍처의 “가장 약한 고리”가 환경의 다른 측면들이 받는 계획 수준의 이점을 누리지 못하는 경우입니다. 이는 예를 들어 가장 잘 설명할 수 있습니다. SIOS 고객 경험 팀은 유지 관리를 중심으로 광범위하게 설계하는 고객과 협력한 적이 있습니다.SAP 애플리케이션해당 환경에서 실행 중이었고 SAP 애플리케이션을 실행하는 시스템에 영향을 미치는 문제로부터 매우 잘 보호되어 있었습니다. 안타깝게도 이 고객은 애플리케이션 보호에 많은 계획 노력을 투자했지만, 환경의 다른 측면에는 동일한 계획 노력을 기울이지 않았습니다. 결과적으로 모든 시스템은 사설 네트워크 내의 호스트를 확인하는 단일 내부 DNS 시스템에 의존하게 되었습니다.수액DNS 시스템에 문제가 발생했을 때, 이름 확인이 더 이상 불가능해지면서 전체 환경에 심각한 문제가 발생했습니다. SAP 애플리케이션을 보호하기 위해 기울인 노력은 사실상 문제 해결에 도움이 되지 않았습니다. DNS가 다른 모든 시스템이 제대로 작동하기 위해 의존하는 “약한 연결 고리”였기 때문입니다. 환경을 계획할 때는 한 걸음 물러나 더 큰 그림을 보는 것이 중요합니다. 아키텍처에서 가장 취약한 연결 고리에 주의를 기울여야 합니다. 가장 취약한 연결 고리를 개선하면 전체 환경이 재해를 견뎌낼 수 있는 잠재력이 높아집니다.

클라우드 서비스에 크게 의존하는 조직의 경우, 지역 또는 지역 전체의 재해로부터 어떻게 보호할 수 있습니까?

지역 또는 지역 전체 재해로부터 보호하는 것은 리소스를 지리적으로 분산하는 것만으로도 가능합니다. 예를 들어, 미국 동부 지역에 기본 애플리케이션 서버를 호스팅할 수 있습니다. 그런 다음 미국 동부 지역에 영향을 미치는 중단으로부터 보호하기 위해 미국 동부 지역(미국 서부 지역일 수 있음)에서 멀리 떨어진 “재해 복구 사이트”에 대기 시스템을 호스팅합니다. 이는 지역 간 통신을 보장하기 위한 몇 가지 추가 단계를 도입하지만, 지역 및 지역 전체 수준의 재해로부터 보호하므로 매우 중요합니다. 클라우드 제공업체의 미국 동부 지역 전체가 중단되더라도 미국 서부 지역에서 애플리케이션을 서비스로 전환하면 견딜 수 있습니다. 특정 지역에서 발생하는 중단으로부터 보호하는 것은 복잡할 필요가 없으며, 운영을 위해 재해 복구 사이트를 확보하면 프로덕션 환경에서 애플리케이션 가용성과 데이터 중복성이 향상됩니다.

조직이 강력한 HA/DR 전략을 구현하는 데 따르는 복잡성과 비용, 그리고 비즈니스 민첩성의 필요성 사이에서 균형을 맞추기 위해 어떤 방법을 권장하시나요?

HA/DR 솔루션은 복잡하거나 비용이 많이 들거나, 아니면 둘 다라는 생각이 널리 퍼져 있습니다. 이러한 가정에 따라, 당면한 위험에 대해 확고한 관점을 유지하는 것이 중요합니다. 시스템은 특정 비즈니스 목적으로 작동하며, 이는 수익 창출로 이어집니다. 시스템 중단으로 인해 시스템이 다운되면 수익 손실 외에도 훨씬 더 많은 비용이 발생합니다. HA/DR 전략이 없다면, 중단 발생 시 직원들이 적극적으로 문제 해결에 나서야 하므로, 다운타임 비용에 직원 근무 시간 비용이 반영될 수 있으며, 심지어 직원들이 충분한 휴식을 취하지 않고 최선을 다할 준비가 되어 있지 않은 시간에도 다운타임 비용이 발생할 수 있습니다. 이 외에도, 정규 업무 중단 및 직원들이 운영 문제 해결로 전환한 후 다시 정규 업무로 복귀해야 하는 지연/느림 현상과 같은 부수적인 비용이 발생합니다. 더 나아가, 수익 창출 기회를 인식하지 못하게 하는 평판 손실도 발생할 수 있습니다. 예를 들어, 다음과 같은 경우를 생각해 보세요.“크라우드스트라이크”? 이것이 즉시 가져오지 않더라도문제와 관련된 나쁜 언론 보도CrowdStrike가 2024년 7월에 경험했던 것과 같은 상황입니다. 이 글을 쓰는 시점(2025년 3월 25일)을 고려하면, 주가는 2024년 7월 19일 발행 이전 수준으로 간신히 회복되었습니다. HA/DR 솔루션 구성의 기회 비용을 고려할 때, 앞서 언급한 요소들은 분석 결과를 크게 바꿀 수 있습니다. 일반적으로 SIOS 고객은 HA/DR 솔루션 구현을 통해 장기적으로 비용을 절감할 수 있습니다. 또한, SIOS Technology의 HA/DR 솔루션에 대한 수십 년간의 개선 및 반복을 통해 이러한 솔루션 구성의 복잡성은 그 어느 때보다 접근하기 쉽고 간소화되었습니다. HA/DR 솔루션을 프로덕션 환경에 도입하는 데 있어 여전히 복잡성에 대한 우려를 불러일으키는 요소가 있다면, SIOS Technology는 팀 교육, 설치 및 구성 작업 수행, 또는 기존 구성의 검증을 지원하는 전문 서비스를 제공합니다. 이러한 기회를 통해,시스템 아키텍처에 고가용성 도입이전보다 훨씬 간편해졌을 뿐만 아니라, 그 어느 때보다 빠르게 구현할 수 있습니다. 마지막으로, 고유한 구성으로 인한 복잡성을 우려하거나 HA/DR 솔루션의 최대 효용성을 달성하려는 기업을 위해, 세계적인 수준의 지원팀이 모든 구현이 최대한의 잠재력을 발휘할 수 있도록 지원해 드립니다.

SIOS Technology의 솔루션은 조직이 귀하가 옹호하는 재해 복구 접근 방식을 구현하는 데 어떤 역할을 합니까?

SIOS Technology의 솔루션이전에 언급한 모든 측면을 충족할 수 있으며, 그 중 일부를 다시 설명하면 다음과 같습니다.

재해 복구에 대한 현대적 접근 방식은 다음을 통해 채택됩니다.LifeKeeper 및 DataKeeper 제품우리는 이를 함께 부릅니다SIOS 보호 제품군Linux 또는 Windows 기반에서 이러한 제품은 클러스터 전체 리소스 오케스트레이션을 제공하여 재해 발생 시 신속하고 효율적인 대응을 보장하는 동시에 대기 시스템에서 데이터가 복제되어 사용 가능하도록 보장합니다. LifeKeeper는 애플리케이션의 장애를 모니터링하고 노드 간 통신을 통해 시스템이 애플리케이션 복구의 유효한 대상인지 확인합니다. Datakeeper는 실시간으로 데이터를 복제하여 문제 발생 시 대기 시스템이 애플리케이션을 상속하고 최신 데이터로 운영을 계속할 수 있도록 보장합니다. 이러한 제품들은 서로 긴밀히 협력하여 애플리케이션 다운 시간을 최소화하고 재해 발생 시 데이터 손실을 최소화합니다.

이러한 제품은 사용자 환경에 완벽하게 통합됩니다. 효율적인 네트워킹 제어를 제공하는 메커니즘을 통해 클라이언트는 항상 애플리케이션 서버와의 연결을 확인할 수 있습니다. 이 솔루션은 애플리케이션이나 시스템의 특정 구성 요소뿐만 아니라 전체 시스템과 환경까지 모니터링합니다. “쿼럼” 기능을 통해 전체 환경을 “전체 상황” 수준에서 모니터링하여 애플리케이션이 올바른 시스템에 복원되고 데이터가 보호되도록 보장합니다. SIOS Protection Suite는 다양한 재해 시나리오에 대한 보호 기능을 갖추고 있어 상황에 적절하게 대응할 수 있습니다.

SIOS Protection Suite는 여러 리전에서 작동하여 앞서 설명한 영역 또는 리전 수준 재해로부터 보호 기능을 제공합니다. 애플리케이션은 여러 리전으로 마이그레이션될 수 있으며, 데이터는 동일 리전 내에서 복제하는 것과 동일한 용이성으로 여러 리전에서 복제될 수 있습니다. 또한, 환경을 다계층화할 수 있습니다. 여러 노드를 기본 리전에 호스팅하여 활성 또는 대기 시스템으로 작동시켜 시스템 수준 문제에 빠르게 대응할 수 있습니다. 또한, 다른 리전에 재해 복구 사이트를 유지 관리하여 동일한 속도와 효율성으로 리전 수준 재해로부터 보호할 수 있습니다.

마지막으로, SIOS Protection Suite 제품은 수십 년간의 실제 사용 경험을 바탕으로 그 가치를 인정받고 있습니다. 다양한 시나리오와 배포 구성에서 검증되었으며, 수년간의 사용 편의성 개선을 통해 그 가치를 입증했습니다. 그 결과, 유연하고 도입이 쉬우며 운영 환경에 완벽하게 통합되는 솔루션이 탄생했습니다. SIOS Protection Suite를 도입하면 HA/DR 솔루션 설계 및 구성의 복잡성을 피할 수 있으며, 풍부한 개발 경험과 수많은 개선 사항, 그리고 발생하는 모든 질문이나 우려 사항에 도움을 줄 수 있는 세계적인 수준의 지원팀의 이점을 누릴 수 있습니다. 이 모든 것 외에도, SIOS Protection Suite 제품에 대한 공동 설치 또는 검증 절차를 통해 어떤 상황에도 대비할 수 있는 환경을 구축할 수 있습니다. 마지막으로, 경험이 풍부한 직원이 필요하고 SIOS Protection Suite와 그 구성 요소의 활용도를 극대화하려는 팀을 위해 SIOS는 팀이 직원과 협력하여 관련 구성 요소를 이해하고 활발한 토론을 통해 직원이 솔루션을 구현하는 데 필요한 모든 정보를 갖추고 바로 작업에 착수할 수 있도록 심층적인 이해를 촉진할 수 있는 교육 참여를 제공합니다.

가동 중지 및 데이터 손실로부터 비즈니스를 보호하세요.데모 요청또는무료 체험판을 시작하세요SIOS가 실제로 어떻게 활용되는지 확인하세요.

저자: 필립 메리, SIOS Technology Corp.의 CX – 소프트웨어 엔지니어

허가를 받아 재생산되었습니다.시오스

DataKeeper와 Baseball: 재해 복구에 대한 전략적 접근

내 경력 전반에 걸쳐데이터키퍼데이터 보호와 관련하여 “싱크탱크” 및 “워터쿨러” 대화에서 업계 표준이 되고 있습니다.재해 복구미국의 대표적인 스포츠인 야구와 DataKeeper를 비교해 보면 어떨까요? 저는 야구를 정말 좋아하지만, 이 둘은 겉보기에는 전혀 관련이 없어 보이지만, 몇 가지 공통점이 있습니다.

데이터 보호를 위한 성공적인 게임 플랜 구축

무엇보다도 Baseball과 DataKeeper 모두 철저한 “게임 플랜”을 요구합니다. 야구에서 팀들은 승리를 위해 상대를 압도하기 위한 전략을 연습하고 고안해 왔습니다. 마찬가지로 DataKeeper는 데이터 보호를 효과적으로 활용하고 심각한 사고 발생 시 복구할 수 있도록 “사고를 자극하는” 전략을 요구합니다.

둘째, 팀워크가 여전히 가장 중요합니다. 내야수, 외야수, 감독, 그리고 배트보이 모두 각자의 역할을 수행하여 승리 가능성을 최대한 높입니다. DataKeeper를 사용하면 데이터베이스 관리자, 인프라 담당자, 고객 경험/지원, 관리팀 등 여러 팀이 참여할 수 있습니다. 모든 팀은 데이터를 효과적으로 보호하고 복구하는 데 철저히 투자해야 합니다.

야구와 DataKeeper의 차이점: IT 분야에서는 위험이 더 큽니다.

간과할 수 없는 몇 가지 차이점이 있습니다. 특히 월드 시리즈 7차전, 마지막 이닝, 2아웃, 3볼, 2스트라이크 상황에서 야구 경기에서 패배하는 것은 “실망스러운” 일이 될 수 있지만, DataKeeper를 사용하면 그 위험은 훨씬 더 커집니다. 데이터 손실은 기업에 심각한 결과를 초래할 수 있습니다. 야구 선수에게는 특별한 운동 능력이 필요한 반면, DataKeeper는 엔터프라이즈 시스템 및 관련 프로세스에 대한 지식을 필요로 하는 솔루션입니다.

요약하자면, 야구와 DataKeeper는 완전히 다른 것처럼 보일 수 있지만, 결론적으로 몇 가지 공통점을 찾을 수 있습니다. 두 가지 모두 다음이 필요합니다.

• 전략
• 팀워크
• . . . 및 전문성

야구 팬이든 IT 전문가이든 성공하려면 일정 수준의 기술과 헌신이 필요하다는 것은 자명한 사실입니다.

귀하의 데이터 보호 계획은 무엇입니까?

제공되는 게임 계획/솔루션을 확인하세요.us.sios.com/솔루션/

공을 가지고 놀자…

저자: SIOS의 수석 제품 지원 엔지니어 Gregory A. Tucker

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

SQL Server 가동 중지 위험에 대한 예산 책정

~ 안에이것TechRadar Pro 기사 “SQL Server 다운타임 위험 예산 책정”에서 SIOS의 데이브 버밍햄은 미션 크리티컬 SQL Server 배포의 중단을 완화하기 위해 비즈니스 연속성 계획을 현실적인 예산에 맞춰 조정하는 것의 중요성을 강조합니다. 그는 조직이 각 SQL Server 인스턴스의 중요성을 평가하고, 매출 손실, 생산성 저하, 데이터 손상, 법적 처벌 등 다운타임의 잠재적 영향을 파악하며, 온프레미스, 클라우드 또는 하이브리드 환경 등 어떤 환경이든 적절한 리소스를 할당하여 재해 대비 태세를 유지하도록 조언합니다.

에서 재생산됨시오스

Linux용 SIOS DataKeeper에서 DRBD로 마이그레이션

SIOS는 DRBD(Distributed Replicated Block Device) 복구 키트를 도입했습니다.Linux용 SIOS LifeKeeper 버전 9.9.0. 에서 마이그레이션SIOS 데이터키퍼Linux에서 DRBD로 전환하는 것은 DRBD 기능을 실험하고 싶은 사람들에게 간단한 프로세스입니다.라이프키퍼DRBD에 대해 이전에 잘 알고 있던 사람들에게도 해당됩니다.

DRBD와 LifeKeeper의 이점 이해

DRBD는 호스트 간에 블록 장치(하드 디스크, 파티션, 논리 볼륨 등)의 콘텐츠를 미러링하는 소프트웨어 기반, 비공유 복제 스토리지 솔루션입니다. LifeKeeper for Linux DRBD Recovery Kit은 고가용성을 위해 DRBD 리소스를 구성하고 제어할 수 있는 기능을 제공합니다.

Linux와 DRBD용 SIOS DataKeeper 비교

Linux용 SIOS DataKeeper는 LifeKeeper 환경에 통합된 데이터 미러링 기능을 제공합니다.고가용성 클러스터(SIOS LifeKeeper를 사용하여) 공유 스토리지가 없거나, 단순히 서버 간에 비즈니스에 중요한 데이터를 실시간으로 복제하려는 사용자입니다.

SIOS DataKeeper는 기본 서버(미러 소스)에서 하나 이상의 백업 서버(미러 대상)로 데이터를 복제하기 위한 동기식 또는 비동기식 볼륨 수준 미러링을 제공합니다. PostgreSQL 리소스를 만드는 단계는 이 블로그에서 제외되었지만 SIOS LifeKeeper를 사용하여 PostgreSQL을 구성하는 방법에 대한 자세한 정보는 다음에서 찾을 수 있습니다.여기.

PostgreSQL 데이터베이스를 DRBD로 마이그레이션하는 방법

1. LifeKeeper UI를 통해 PostgreSQL 애플리케이션 중지

lkcli 리소스 제거 –tag pgsql-demo

1. PostgreSQL 데이터베이스 및 로그 파일에 대한 데이터 백업을 만듭니다.

cp -pra /pgsql-demo* /백업/

1. 임시 파일 시스템 위치로 새로운 DRBD 리소스를 만듭니다.

lkcli 리소스 생성 drbd –tag drbd-pgsql-demo –device /dev/mapper/singledrbd-lk1 –fstype ext3 –mount_point /tmp/pgsql-demo

이전 DataKeeper for Linux 리소스와 동일한 fstype을 선택해야 합니다. 선택한 장치는 PostgreSQL 데이터베이스 데이터 세트의 데이터 및 로그 양을 충분히 수용할 수 있어야 합니다.

1. DRBD 리소스를 대상 서버로 확장합니다.

lkcli 리소스 확장 drbd –tag drbd-pgsql-demo –dest node-a –device /dev/xvdc3 –mode 동기식 –laddr 10.15.29.165 –raddr 10.15.27.49

1. PostgreSQL 데이터베이스의 파일 시스템 리소스를 서비스에서 제외합니다.

lkcli 리소스 제거 –tag /pgsql-demo

1. /tmp/pgsql/demo 디렉토리의 소유자와 그룹을 변경합니다.

chown postgres:postgres /tmp/pgsql/demo

1. DRBD 미러링된 파일 시스템에 데이터를 복사합니다.

cp -pra /백업/* /tmp/pgsql-데모

1. 새로 생성된 DRBD 파일 시스템 리소스를 서비스에서 제거합니다.

lkcli 리소스 제거 –tag /tmp/pgsql-demo

1. 이전 파일 시스템과 Linux 리소스용 DataKeeper 간의 종속성을 끊습니다.

lkcli 종속성 삭제 –parent /pgsql-demo –child datarep-pgsql-demo

파일 시스템과 DRBD 리소스 간의 종속성을 끊습니다.

lkcli 종속성 삭제 –parent /tmp/pgsql-demo –child drbd-pgsql-demo

1. 기존 /pgsql-demo 파일 시스템과 drbd 리소스 간의 종속성을 다시 생성합니다.

lkcli 종속성 생성 –parent /pgsql-demo –child drbd-pgsql-demo

1. pgsql-demo 리소스 시작

lkcli 리소스 복원 –tag pgsql-demo

서버 “node-b”에서 “pgsql-demo” 복원 시작

서버가 시작될 때까지 기다리는 중… 완료

서버가 시작되었습니다

서버 “node-b”에서 “pgsql-demo”의 성공적인 복원이 완료되었습니다.

1. 데이터베이스에 연결하고 데이터베이스 연결을 확인합니다.

예를 들어:

psql -p 3308 -h /pgsql-demo/socket -U psql

psql -p <포트> -h <소켓 디렉토리> -U <db 사용자>

1. 임시 DRBD 파일 시스템 리소스를 제거합니다.

lkcli 리소스 삭제 /tmp/pgsql-demo

1. Linux용 DataKeeper의 datarep 및 임시 파일 시스템 리소스를 제거합니다.

lkcli 리소스 삭제 –tag datarep-pgsql-demo

15. 전환 및 연결 확인

Linux용 SIOS DataKeeper에서 DRBD로 마이그레이션해야 하는 이유는 무엇입니까?

Linux용 SIOS DataKeeper에서 DRBD로 마이그레이션하는 것은 LifeKeeper 내에서 DRBD 기능을 실험하고 싶은 사용자뿐만 아니라 이전에 DRBD에 대해 더 잘 알고 있거나 DRBD의 더 빠른 비동기 복제 속도와 더 광범위한 커널 지원을 활용하고 싶은 사용자에게도 간단한 프로세스입니다.

DRBD를 시작할 준비가 되셨나요?지금 SIOS에 문의하세요LifeKeeper가 어떻게 원활하게 마이그레이션하고 고가용성 및 재해 복구를 위한 DRBD의 모든 잠재력을 활용할 수 있도록 도와주는지 알아보세요.

저자: SIOS Technology Corp.의 고객 경험 담당 부사장, Cassius Rhue

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