SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

고가용성을 위한 IT 시스템 최적화 전략

6월 5, 2024 by Jason Aw Leave a Comment

Strategies for Optimizing IT Systems for High Availability

고가용성을 위한 IT 시스템 최적화 전략

IT 시스템의 고가용성(HA)을 유지하는 것은 조직의 성공에 필수적입니다. 중요한 데이터베이스 관리부터 원활한 고객 경험 보장까지 중단 없는 운영을 달성하려면 전략 계획이 필요한 고유한 과제가 필요합니다. 다음은 조직이 고가용성을 위해 IT 시스템을 최적화하기 위해 활용할 수 있는 몇 가지 주요 전략입니다.

고가용성을 위한 IT 시스템 최적화의 일반적인 과제

IT 시스템에 문제를 제기하기 시작하는 몇 가지 영역이 있습니다. 자주 언급되는 문제 중 하나는 바이러스 백신(AV) 솔루션과의 호환성입니다. 종종 문제는 바이러스 백신이 시스템을 과도하게 보호하고 응용 프로그램이나 HA 솔루션 기능에 중요한 파일을 격리하는 데서 발생합니다. 물론 솔루션 간의 호환성을 확인하고 한 단계 더 나아가는 것이 항상 중요합니다. 시스템을 관리하는 모든 사람이 AV 솔루션의 작동 방식을 숙지하고 AV에 대한 변경을 구성/요청하는 절차를 이해하는 것이 항상 좋습니다. 중요한 애플리케이션이 중단되지 않도록 솔루션을 제공합니다.

AV 솔루션 외에도 방화벽 구성도 나타납니다. HA 솔루션에서는 클러스터 동작을 조정하기 위해 네트워크를 통해 추가 통신이 전송되는 경우가 많습니다. 결과적으로 일반적으로 HA 솔루션에 의한 잘못된 클러스터 복구 작업을 방지하기 위해 HA 솔루션을 수용하기 위해 추가해야 하는 특정 규칙이 있습니다.

마지막으로, 고가용성 시스템을 구성할 때 액세스 제어 원칙은 약간 더 복잡해집니다. 개별 팀(IE, DB 팀, SAP 팀, 클라우드 팀 – 분산 여부)은 각각 해당 도메인에 대한 권한이 필요하지만 HA 솔루션을 관리하는 모든 관리자는 HA 솔루션(IE)을 통해 액세스할 수 있는 추가 권한이 있음을 확인할 수 있습니다. , 애플리케이션 장애 조치 시작, 노드 간 통신 생성, 스토리지 잠금/잠금 해제 등). 따라서 접근 권한을 위임할 때 HA 솔루션을 통해 가능한 조치를 고려하는 것이 중요합니다. 루트 수준 사용자에게만 HA 제어를 허용하는 것이 적절할 수도 있고, HA 솔루션을 통해 조치를 취하는 절차를 정의하여 팀에 알리고 조치를 추적할 수도 있습니다. 그럼에도 불구하고, 최소 권한 원칙의 관점에서 HA 솔루션은 애플리케이션과 시스템이 위임된 당사자만 액세스하고 변경할 수 있도록 보장하기 위해 고려해야 할 복잡성을 제시합니다.

시스템 가동 시간 보장에서 장애 조치 및 재해 복구 전략의 역할

장애 조치 기능과 재해 복구(DR) 전략은 모두 중요한 시스템의 가동 시간에 상당한 영향을 미칩니다. 분명히 HA는 단일 서버 문제로 인해 애플리케이션 제품군이 중단되지 않도록 장애 조치 기능을 제공할 수 있으며 올바르게 구성되면 장애 조치가 거의 원활하게 이루어질 수 있습니다. 이를 통해 대기 시스템이 로드를 픽업하는 기본 역할을 맡는 동안 오류가 발생한 시스템에서 복구를 진행할 수 있습니다. 물론 재해 복구는 HA 전략과 긴밀하게 결합될 수 있습니다. 중복성이 이미 구성되어 있는 경우 이 중복성이 장애 도메인 전체에 존재하는지 확인하는 것이 좋습니다. 올바르게 관찰하면 애플리케이션의 가용성과 내결함성이 높아질 수 있습니다. IT 관점에서 이러한 결과를 분석할 때 적절하게 구성된 HA 및 DR 전략을 사용하면 가동 중지 시간을 최소화하면서 시스템의 잠재력을 최대한 활용할 수 있습니다. 애플리케이션이 호스팅되는 지역의 자연재해나 기술적 장애가 다른 지역으로 전파될 가능성은 훨씬 적습니다. 재해 복구 계획과 함께 계획된 중복성을 활용하면 더 적은 리소스로 더 많은 기능 요구 사항을 충족할 수 있습니다. 신중한 계획을 통해 대기 사이트 배포에서 중복성과 내결함성을 모두 처리할 수 있기 때문입니다.

비용 효율성과 고가용성의 균형: 조직을 위한 전략

클러스터 환경이나 고가용성 시스템을 구성하려면 비용이 많이 들 수 있습니다. 일반적으로 하나 이상의 대기 시스템이 기본 시스템과 함께 실행되고 워크로드를 처리하지 않음에도 불구하고 비용이 발생하지만 비용은 완화될 수 있습니다. 이에 대해 제가 제안하는 몇 가지 방법은 다음과 같습니다. 관리형 공유 스토리지 솔루션을 사용해 보세요. 데이터의 중복 복사본이 필요하지 않은 경우 공유 저장소를 사용하여 저장소를 절약할 수 있습니다. Amazon EFS와 같은 것은 복제된 디스크 구성에 비해 스토리지의 절반만 비용을 지불하면 된다는 것을 의미할 수 있습니다.

DR 시스템의 사용 사례를 고려하십시오. 종종 이러한 시스템은 기본 사이트가 복구되는 동안 임시방편으로 사용되는 솔루션입니다. 리소스는 장기간 DR 사이트에서 실행되지 않으므로 워크로드에 따라 DR 사이트에 더 작은 시스템을 프로비저닝하여 컴퓨팅 비용을 절약할 수 있습니다. 물론 여기에서 설계 결정을 이해관계자와 소통하여 모든 사람이 DR 사이트가 장기 호스팅 솔루션이 아니라는 점을 인식해야 합니다. 하지만 워크로드와 인력이 추가된 제한을 처리할 수 있다면 인스턴스 크기를 절약할 수 있습니다. 같은 맥락에서, 작업 부하를 호스팅하지 않고 클러스터 내에서만 조정하는 오케스트레이터 및/또는 쿼럼 시스템은 작업 부하가 위임되는 시스템보다 훨씬 작을 수 있습니다.

확장 또는 확장 솔루션 사용을 고려해 보세요. 확장이란 단일 시스템의 컴퓨팅 용량을 늘리는 것을 의미합니다. 클라우드 환경에서 이는 워크로드가 작은 인스턴스를 압도할 때 작은 인스턴스가 리소스 풀을 더 큰 인스턴스의 리소스 풀로 늘리는 것과 관련이 있습니다. 수평 확장이란 컴퓨팅 성능이 필요할 때 애플리케이션의 로드를 공유할 작업자 수를 늘리는 것을 의미합니다. 분명히 사용 사례에 따라 확장 또는 확장이 더 나은 솔루션인 시기와 위치가 결정됩니다. 그러나 현재 소프트웨어와 환경에 익숙해지면 결정을 내리고 때가 되면 적절하게 작동하도록 시스템을 구성할 수 있습니다. 스케일링 솔루션과 관련하여 고려해야 할 또 다른 사항은 스케일 제거 규칙의 강도를 고려하는 것입니다. 비용을 절약하려면 인스턴스가 적절한 리소스 풀로 다시 축소되는지 확인하고 축소 동작을 지시하는 규칙을 평가하여 과도한 리소스를 필요 이상으로 오랫동안 프로비저닝하지 않도록 하십시오. IT 팀, 이해 관계자, 사이버 보안 팀 간의 강력한 커뮤니케이션을 구축하십시오. 및 HA 공급업체. 의사소통 기반을 확보하면 기술의 협력적 출시나 환경 업그레이드를 촉진할 수 있습니다. 또한 커뮤니케이션을 활발하게 유지함으로써 모든 팀은 시스템에서 발생하는 활동에 대해 더 잘 알게 될 것입니다. 모든 팀을 최신 상태로 유지하는 것이 중요하며 필요한 경우 문제를 진단하거나 롤백 절차를 시작하는 것이 훨씬 더 쉬워질 수 있습니다. 마지막으로, 강력한 의사소통을 유지하면 팀 간에 모범 사례를 효율적으로 공유할 수 있으므로 팀은 서로 다른 원칙에 따라 운영하기보다는 협력적으로 작업할 수 있습니다.

고가용성 구현: 모범 사례

시스템을 배포하는 모든 사람에게 권장하는 첫 번째이자 가장 큰 방법은 테스트 환경을 유지하는 것입니다. 테스트 환경을 프로덕션 환경과 최대한 동일하게 유지하고 프로덕션 환경에서 발생하는 모든 절차를 시험 실행하여 팀이 프로덕션 롤아웃이 발생할 때 절차와 런북을 잘 숙지할 수 있도록 합니다. 이 관행은 제가 시스템에 제공할 다른 모범 사례에도 적용됩니다. 테스트 환경을 유지함으로써 변경 사항을 사전 테스트하는 데 사용할 수 있는 시스템도 유지 관리하게 됩니다. 테스트 환경은 제품 호환성을 검증하고 기술 간 상호 운용에 대한 고려 사항이 잘 확립되어 있는지 확인하기에 완벽한 장소입니다. 내가 몇 번이고 보는 환상적인 예는 바이러스 백신 소프트웨어에 대한 제외를 구성하는 것입니다. 이러한 제외가 구성되지 않고 바이러스 백신이 매우 자주 액세스하는 파일을 격리할 수 있기 때문에 프로덕션 환경이 중단되는 경우가 있습니다. 마지막으로 구성을 정기적으로 감사하고 있는지 확인하세요. 보안 그룹, 액세스 제어, 방화벽 규칙 및 소프트웨어 호환성(특히 HA, 보호된 애플리케이션 및 바이러스 백신 간)과 같은 다양한 측면을 검토합니다. 이러한 감사 결과에 따른 발견 사항 및 변경 사항에 대한 강력한 로그를 유지하십시오. 이러한 세부 사항을 추적하면 문제를 일으키는 구성 변경이 있는 것으로 보이는 경우 검토할 수 있는 견고한 기록이 제공됩니다. 또한 공급업체에 지원을 요청할 때 이러한 감사는 전체 근본 원인 분석에 더 빨리 도달하기 위해 공유할 수 있는 환상적인 도구가 될 수 있습니다. 무엇보다도 이러한 감사는 구성 방법에 대한 기록을 제공하는 역할을 합니다. 정해진 구성에 변경 사항이 있는 경우 과거 감사 결과를 다시 참조하여 조직의 표준에 맞게 시스템을 재정렬할 수 있습니다. 시스템 설정.

SIOS는 고가용성을 위해 IT 시스템을 최적화하는 것이 조직의 성공에 중요하다는 것을 이해합니다. 바이러스 백신 솔루션과 미세 조정 방화벽 구성을 통해 호환성 문제를 해결함으로써 조직은 시스템 복원력과 가동 시간을 향상시킬 수 있습니다.자세한 내용은 지금 문의하세요.

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

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

SIOS 기술은 고가용성과 클라우드 비용 간의 균형을 맞추는 데 도움이 됩니다.

5월 26, 2024 by Jason Aw Leave a Comment

SIOS Technology helps strike the balance between high availability and cloud costs

SIOS 기술은 고가용성과 클라우드 비용 간의 균형을 맞추는 데 도움이 됩니다.

 

사이의 적절한 균형 찾기고가용성비용 최적화가 어려울 수 있습니다. SIOS Technology의 수석 기술 전도사인 Dave Bermingham은 클라우드 비용에 영향을 미치는 몇 가지 주요 요소와 비용 최적화 전략에 대해 설명합니다. 그는 “우리는 고가용성을 배포하는 것뿐만 아니라 계획된 유지 관리와 관련된 가동 중지 시간을 최소화하는 것 외에도 예기치 않은 가동 중지 시간을 최소화하는 데 관련된 비용을 줄이는 데 도움이 되는 실용적이고 효과적인 전략에 중점을 둡니다.”라고 말합니다.

클라우드 환경의 비용에 영향을 미치는 주요 요소

  • 고가용성 구성에서 클라우드 비용에 영향을 미치고 비용을 최적화하는 주요 요소에는 효율적인 리소스 관리, 전략적 아키텍처 결정 및 지속적인 모니터링이 포함됩니다.
  • Bermingham은 워크로드 요구 사항에 맞게 올바른 인스턴스, 유형 및 크기를 선택하는 것이 어떻게 중요한지, 자동 확장이 비용을 절감하고 클라우드 지출을 최적화하는 데 어떻게 도움이 되는지 설명합니다.
  • Bermingham은 고가용성 솔루션이 여러 시간대에 걸쳐 배포되는 경우 데이터 전송 비용을 고려하는 것이 중요하며 요금을 최소화하는 데 사용할 수 있는 전략을 강조합니다.
  • 기타 주요 고려 사항에는 스토리지 최적화, 효과적인 거버넌스 및 비용 관리 정책 구현이 포함됩니다.

클라우드에서 고가용성과 비용 최적화 사이의 균형 찾기

  • Bermingham은 고가용성으로 인해 약간의 비용이 발생하기는 하지만 가동 중지 시간과 관련된 비용(상당할 수 있음)을 상쇄한다고 설명합니다.
  • 모듈식이며 확장 가능한 시스템을 구축하고 DevOps 문화를 수용하고 CI/CD 방식을 활용하는 운영 전략을 통해 고가용성과 클라우드 비용 최소화 사이의 균형을 유지하는 것이 중요합니다.

클라우드 비용 최적화 및 고가용성 과제

  • Bermingham은 클라우드 비용 관리의 복잡성을 과소평가하고 애플리케이션 성능 모니터링의 중요성을 무시하는 등 고가용성을 저하하지 않고 비용을 최적화하는 일반적인 함정을 강조합니다.
  • 클라우드 비용 최적화 모범 사례 및 HA 솔루션 구현에 대한 부적절한 교육은 종종 비효율적인 리소스 활용 및 계획되지 않은 가동 중지 시간으로 이어질 수 있습니다.

SIOS Technology의 고가용성 솔루션이 어떻게 도움이 됩니까?

  • Bermingham은 SIOS 기술이 다양한 클라우드 환경에서 HA를 단순화 및 자동화하여 비용을 최소화하고 가동 중지 시간을 최소화하며 유지 관리를 관리하는 HA 솔루션을 통해 이러한 문제를 해결하는 데 어떻게 도움이 되는지 설명합니다.

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

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

Linux v 9.8.1용 SIOS LifeKeeper는 기업이 HA/DR을 관리하는 방식을 개선합니다.

5월 22, 2024 by Jason Aw Leave a Comment

SIOS LifeKeeper for Linux v 9.8.1 improves the way companies manage HA/DR

Linux v 9.8.1용 SIOS LifeKeeper는 기업이 HA/DR을 관리하는 방식을 개선합니다.

오늘날의 기술 중심 환경에서 기업은 복잡한 애플리케이션 환경을 효과적으로 유지하기 위한 혁신적인 솔루션을 찾고 있습니다. 이 영상에서는,토드 도안SIOS Technology의 영업 엔지니어가 최신 버전의Linux용 SIOS LifeKeeper기업이 가동 중지 시간과 재해로부터 중요한 기업 시스템을 보호하는 데 도움이 됩니다. “이번 릴리스에는새로운 웹 관리 콘솔. 독립형이므로 추가 설치나 타사 추가 기능이 필요하지 않습니다.”라고 Doane은 말합니다.

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

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

GenApp과 QSP 중 선택: 중요한 애플리케이션에 대한 고가용성 조정

5월 17, 2024 by Jason Aw Leave a Comment

Choosing Between GenApp and QSP Tailoring High Availability for Your Critical Applications

GenApp과 QSP 중 선택: 중요한 애플리케이션에 대한 고가용성 조정

GenApp 또는 QSP? 두 솔루션 모두 LifeKeeper에서 지원되며 중요한 애플리케이션의 가동 중지 시간을 방지하는 데 도움이 되지만 특정 요구 사항에 맞는 올바른 솔루션을 선택하려면 이러한 솔루션 간의 미묘한 차이를 이해하는 것이 중요합니다. 다음은 귀하의 환경에 가장 적합한 기능을 결정할 수 있는 몇 가지 기능, 이점 및 잠재적 사용 사례입니다.

젠앱,일반 애플리케이션(Generic Application)의 약어는 LifeKeeper 내에서 사용자 정의 애플리케이션을 관리할 수 있는 리소스 유형입니다. 유연한 프레임워크를 사용하면 자체 스크립트를 사용하여 애플리케이션에서 장애 조치 및 복구 프로세스를 자동화하는 데 필요할 수 있는 다양한 작업을 수행할 수 있습니다. 이러한 유연성을 통해 LifeKeeper가 시작, 종료, 모니터링, 로깅 작업 등을 처리하는 방법을 세부적으로 제어하여 애플리케이션의 고가용성을 보장할 수 있습니다.

QSP또는 Quick Service Protection은 OS 서비스를 빠르고 쉽게 보호할 수 있도록 설계되었습니다. QSP는 이러한 작업에 대해 내장된 조정 가능한 시간 제한을 통해 이러한 애플리케이션의 모니터링, 장애 조치 및 복구를 자동화합니다. 또한 서비스가 필요한 다른 애플리케이션과 함께 서비스를 시작하고 중지할 수 있도록 종속 관계를 생성할 수 있습니다.

올바른 솔루션을 어떻게 선택합니까?

가장 먼저 결정해야 할 것은 서비스나 데몬을 중지했다가 다시 시작하여 애플리케이션을 복구할 수 있는지 여부입니다. 그렇다면 QSP는 아마도 애플리케이션을 계속 실행하는 데 가장 적합하고 빠른 솔루션일 것입니다. 코딩이 필요하지 않으며 몇 분 안에 LifeKeeper GUI 내에서 애플리케이션을 QSP 리소스로 추가할 수 있기 때문입니다. 또한 이는 핵심 제품의 일부이며 모든 코딩 업데이트는 새 제품 릴리스에 포함됩니다. 그러나 애플리케이션이 제대로 복구하기 위해 간단한 상태 확인 및 OS 서비스 수준의 재시작 기능 이외의 다른 기능이 필요한 경우 GenApps를 살펴보는 것이 좋습니다. GenApp 리소스 유형에 대한 사용자 정의 스크립트를 생성하려면 더 심층적인 기술과 장기적인 유지 관리가 필요하지만, 특히 틈새 애플리케이션의 경우 애플리케이션을 원활하게 실행하는 데 필요한 모든 작업을 수행할 수 있는 유연성이 중요합니다. 이러한 작업은 모니터링, 로깅, 정리 작업 또는 구성 변경 등 무엇이든 될 수 있습니다.

더 자세한 기술 정보를 원하시나요?

GenApps 및 QSP는 Linux 및 Windows용 LifeKeeper에서 모두 지원됩니다. 자세한 기술 세부 정보는 아래 링크에서 확인할 수 있습니다.

  • Linux용 LifeKeeper용 GenApp
  • Windows용 LifeKeeper용 GenApp
  • Linux용 LifeKeeper용 QSP
  • Windows용 LifeKeeper용 QSP

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

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

장애 조치가 발생하는 원인은 무엇입니까?

5월 11, 2024 by Jason Aw Leave a Comment

What Causes Failovers to Happen

장애 조치가 발생하는 원인은 무엇입니까?

지원 업무를 하면서 우리가 고객으로부터 받는 가장 일반적인 질문 중 하나는 “무엇이장애 조치내 기본 노드에서 보조 노드로?”

이러한 현상이 발생하는 데는 여러 가지 이유가 있습니다. 가장 일반적인 원인과 이를 식별하는 방법을 설명하겠습니다.

시작하기 전에 먼저‘장애 조치’와 ‘전환’을 구별합니다., 많은 고객이 이러한 용어를 같은 의미로 사용하기 때문입니다.

‘전환’은 계층 구조를 기본 노드에서 보조 노드로 수동으로 이동하는 작업입니다. 이 작업은 보조 노드에서 ‘서비스 중’을 수행하거나 명령줄을 통해 GUI를 통해 수행할 수 있습니다.

Perform_action -a Restore -t $LKTag(계층 구조를 서비스로 가져옴)

반면에 ‘장애 조치’는 수동 상호 작용 없이 수행되며 이전에 활성화된 서버, 애플리케이션 또는 하드웨어/네트워크에 오류가 발생하면 백업 서버로 자동 전환되는 것으로 정의됩니다.

장애 조치(failover)와 전환(switchover)은 장애 조치(failover)가 자동이고 전환이라는 점을 제외하면 본질적으로 동일한 작업입니다.보통 경고 없이 작동함, 전환은 의도적이며 사람의 개입이 필요합니다.

다음은 ‘장애 조치’를 시작하는 가장 일반적인 ‘실패’입니다.

  1. 서버 수준 원인

서버 장애

  • 기본 서버의 전원이 꺼지거나 꺼졌습니다.
  • 과도한 로드로 인한 CPU 사용량 — 매우 높은 I/O 로드에서 지연 및 메모리 부족 상태로 인해 시스템이 응답하지 않을 수 있습니다.생명의 수호자서버가 다운된 것을 감지하고 장애 조치를 시작할 수 있습니다.
  • 쿼럼/감시 – 쿼럼/감시 I/O 펜싱 메커니즘의 일부로 기본 서버가 쿼럼을 잃으면 “빠른 부팅“:,”빨리 죽여라” 또는 “오수“가 수행되고(설정에 따라) 장애 조치가 시작됩니다. 장애 조치(failover) 시기를 결정할 때 미러링 모니터 서버는 주 서버가 실패했고 더 이상 클러스터의 일부가 아님을 확인하는 경우에만 리소스가 백업 서버에서 서비스되도록 허용합니다. 이렇게 하면 해당 오류가 서비스 중인 노드에 대한 전반적인 액세스 및 성능에 영향을 미치지 않는 경우 노드 간의 단순한 통신 오류로 인해 발생하는 장애 조치를 방지할 수 있습니다.

통신(하트비트) 실패

LifeKeeper에는 페어링된 서버가 작동 중임을 구성에 있는 각 서버에 주기적으로 알리는 “하트비트” 신호가 내장되어 있습니다. 기본적으로 LifeKeeper는 5초마다 서버 간에 하트비트를 보냅니다(사용량이 많은 클러스터에 대해 조정 가능). 통신 문제로 인해 심장 박동이 두 번 건너뛰었지만 세 번째 심장 박동에서 재개되는 경우 LifeKeeper는 아무런 조치도 취하지 않습니다. 그러나 통신 경로가 3비트 동안 작동하지 않는 경우 LifeKeeper는 해당 통신 경로를 작동하지 않는 것으로 표시합니다. 중복 통신 경로도 작동하지 않는 경우 장애 조치를 시작합니다(두 개의 경로 권장).

다음과 같은 경우 하트비트가 누락될 수 있습니다.

  • 기본 서버에 대한 네트워크 연결이 끊어졌습니다.
  • 네트워크 대기 시간.
  • TCP 통신 경로의 과도한 네트워크 트래픽으로 인해 잘못된 장애 조치 및 LifeKeeper 초기화 문제를 비롯한 예상치 못한 동작이 발생할 수 있습니다.
  • NIC에 오류가 발생했습니다.
  • 네트워크 전환에 실패했습니다.
  • 수동으로 네트워크 연결 풀링/제거
  • 기본 서버의 전원이 꺼지거나 꺼졌습니다.
  • 과도한 로드로 인한 CPU 사용량 — I/O 로드가 매우 심한 경우 지연 및 메모리 부족 상태로 인해 시스템이 응답하지 않게 되어 LifeKeeper가 서버가 다운된 것을 감지하고 장애 조치를 시작할 수 있습니다.

하트비트 매개변수 조정:

LCMNUMHBEATS=Y(여기서 Y는 통신 경로 실패 오류를 로그에 기록하기 전의 하트비트 수입니다). 기본값은 3이며 시스템이 사용량이 많거나 잘못된 통신 경로 실패를 방지하기 위해 WAN을 통과하는 경우 변경할 수 있습니다.

LCMHBEATTIME=5(초 단위 간격이며 기본값이며 변경하면 안 됩니다).

이러한 조정 가능 항목은 기본적으로 /etc/default/LifeKeeper 파일에 없습니다. 하트비트 값을 변경하려면 이를 추가해야 합니다.

/etc/default/LifeKeeper에 이러한 조정 가능 항목과 값을 추가한 후 LifeKeeper를 중지하고 다시 시작해야 합니다. LifeKeeper를 중지하지만 보호된 응용 프로그램을 종료하지 않는 lkstop -f 명령을 사용할 수 있습니다.

그리고 두 시스템 모두에서 이 작업을 수행해야 합니다.

LifeKeeper가 통신 경로를 실패로 표시하기 전에 5회 Y초가 소요됩니다.

분할 브레인(Split-Brain)이란 무엇이며 그 원인은 무엇입니까?

단일 통신 경로가 사용되고 통신 경로가 실패하는 경우 LifeKeeper 계층은 여러 시스템에서 동시에 서비스를 시도할 수 있습니다. 이를 잘못된 장애 조치(failover) 또는 “분할 브레인(split-brain)” 시나리오라고 합니다. 에서“분할 두뇌” 시나리오, 각 서버는 자신이 애플리케이션을 제어하고 있다고 믿고 공유 저장 장치에 액세스하여 데이터를 쓰려고 시도할 수 있습니다. 분할 브레인 시나리오를 해결하기 위해 LifeKeeper는 모든 공유 데이터의 데이터 무결성을 보장하기 위해 서버의 전원을 끄거나 재부팅하거나 계층 구조를 서비스 중단 상태로 둘 수 있습니다. 또한 TCP 통신 경로의 과도한 네트워크 트래픽으로 인해 잘못된 장애 조치 및 LifeKeeper의 적절한 초기화 실패 등 예상치 못한 동작이 발생할 수 있습니다.

다음은 분할 브레인이 발생할 수 있는 시나리오입니다.

  • 위에 나열된 통신 오류 중 하나
  • LifeKeeper의 부적절한 종료
  • 서버 리소스 부족
  • 모든 네트워크 경로 손실
  • DNS 또는 기타 네트워크 결함
  • 시스템 잠금

쿼럼/감시를 사용하여 분할 브레인 방지

  • LifeKeeper용 쿼럼/위트니스 서버 지원 패키지(steeleye-lkQWK, 이하 “쿼럼/위트니스 패키지”)는 LifeKeeper 코어의 기존 장애 조치 프로세스와 결합되어 전체 네트워크 장애가 발생할 수 있는 상황에서 시스템 장애 조치가 더 큰 확신을 가지고 발생할 수 있도록 합니다. 흔하다. 이는 로컬 사이트 장애 조치 및 WAN을 통한 노드에 대한 장애 조치를 수행하는 동시에 다음과 같은 위험을 크게 줄일 수 있음을 의미합니다.분할 두뇌상황.
  • 네트워크 분할을 고려하는 분산 시스템에는 클러스터 전체의 합의를 얻기 위해 쿼럼이라는 개념이 있습니다. 쿼럼을 갖는 노드는 모든 클러스터의 합의를 얻을 수 있고 자원을 서비스에 가져올 수 있는 노드입니다. 반면, 쿼럼이 없는 노드는 모든 클러스터의 합의를 얻을 수 없고 자원을 서비스할 수 없는 노드입니다. 이렇게 하면 분할 뇌가 발생하는 것을 방지할 수 있습니다. 노드에 쿼럼이 있는지 확인하는 것을 쿼럼 확인이라고 합니다. 쿼럼이 있으면 “쿼럼 확인 성공”으로 표시되고, 쿼럼이 없으면 “쿼럼 확인 실패”로 표시됩니다.
  • 통신 오류가 발생한 경우 오류가 발생한 노드 하나와 다른 여러 노드(또는 기타 장치)를 사용하면 노드가 오류가 발생한 노드의 상태에 대한 “2차 의견”을 얻을 수 있습니다. “2차 의견”을 얻는 노드를 증인 노드(또는 증인 장치)라고 하며, “2차 의견”을 얻는 것을 증인 확인이라고 합니다. 장애 조치 시기를 결정할 때 감시 노드(감시 장치)는 기본 서버가 실패했고 더 이상 클러스터의 일부가 아님을 확인하는 경우에만 백업 서버에서 리소스를 서비스할 수 있도록 허용합니다. 이렇게 하면 해당 오류가 서비스 중인 노드에 대한 전반적인 액세스 및 성능에 영향을 미치지 않는 경우 노드 간의 단순한 통신 오류로 인해 장애 조치가 발생하는 것을 방지할 수 있습니다. 실제 작동 중에 LifeKeeper가 시작되거나 실패한 통신 경로가 복원되면 감시 노드(감시 장치)가 참조됩니다. 증인 확인은 쿼럼이 있는 노드에 대해서만 수행할 수 있습니다.
  1. 자원 장애 원인

LifeKeeper는 개별 응용 프로그램 및 관련 응용 프로그램 그룹을 모니터링하고 보호된 응용 프로그램이 실패할 경우 주기적으로 로컬 복구 또는 알림을 수행하도록 설계되었습니다. 예를 들어 관련 애플리케이션은 기본 애플리케이션이 하위 수준 스토리지 또는 네트워크 리소스에 의존하는 계층입니다. LifeKeeper는 이러한 보호된 리소스의 상태를 모니터링합니다. 리소스가 장애 상태로 판단되면 외부 개입 없이 현재 시스템(서비스 중인 노드)에서 리소스나 애플리케이션을 복원하려고 시도합니다. 이 로컬 복구가 실패하면 리소스 장애 조치가 시작됩니다.

신청 실패

  • 애플리케이션 오류가 감지되었지만 로컬 복구 프로세스가 실패했습니다.
  • 오류 제거 – 리소스 장애 조치 프로세스 중에 중요한 애플리케이션의 전체 기능을 제공하려면 특정 리소스를 기본 서버의 서비스에서 제거한 다음 선택한 백업 서버의 서비스로 가져와야 합니다. 이 제거 프로세스가 실패하면 기본 서버 재부팅이 수행되어 완전한 서버 장애 조치가 수행됩니다.

제거 실패의 예:

  • 파일 시스템을 마운트 해제할 수 없습니다.
  • 보호된 애플리케이션(oracle, mysql, postgres 등)을 종료할 수 없습니다.

파일 시스템 문제

  • 디스크 가득 참 – LifeKeeper의 파일 시스템 상태 모니터링은 파일 시스템 리소스의 장애 조치를 초래할 수 있는 디스크 가득 참 파일 시스템 상태를 감지할 수 있습니다.
  • 마운트 해제되거나 잘못 마운트된 파일 시스템 – 사용자가 서비스 내 및 LK 보호 파일 시스템에서 옵션을 수동으로 마운트 해제하거나 변경합니다.
  • 재마운트 실패 – 다음은 장애 조치로 이어질 수 있는 재마운트 실패의 일반적인 원인 목록입니다.
  • 손상된 파일 시스템(fsck 실패)
  • 마운트 지점 디렉터리 생성 실패
  • 마운트 포인트가 사용 중입니다
  • 마운트 실패
  • LifeKeeper 내부 오류

IP 주소 실패

IP 복구 키트에서 IP 주소 오류가 감지되면 결과 오류로 인해 IP 로컬 복구 스크립트가 실행됩니다. LifeKeeper는 먼저 현재 네트워크 인터페이스에서 IP 주소를 다시 서비스하도록 시도합니다. 로컬 복구 시도가 실패하면 LifeKeeper는 IP 주소와 모든 종속 리소스를 백업 서버로 장애 조치합니다. 장애 조치 중에 제거 프로세스는 백업 서버에서 구성될 수 있도록 현재 서버에서 IP 주소의 구성을 해제합니다. 이 제거 프로세스가 실패하면 시스템이 재부팅됩니다.

  • IP 충돌
  • IP 충돌
  • DNS 확인 실패
  • NIC 또는 스위치 오류

예약 충돌

  • 보호된 장치에 대한 예약이 분실되거나 도난당했습니다.
  • 보호된 리소스 장치의 예약 또는 제어를 다시 얻을 수 없음(수동 사용자 개입, HBA 또는 스위치 오류로 인해 발생)

SCSI 장치

  • 보호된 SCSI 장치를 열 수 없습니다. 장치에 오류가 있거나 시스템에서 제거되었을 수 있습니다.

장애 조치 원인을 식별하기 위한 리소스

/var/log/lifekeeper.log

LifeKeeper가 작성한 이 로그 파일은 장애 조치의 원인을 판별할 때 가장 먼저 살펴봐야 할 곳입니다.

예를 들어, 가장 일반적인 이유 중 하나는 통신 경로 오류입니다. 다음은 이러한 상황이 발생할 때 lifekeeper.log에서 찾을 수 있는 항목의 예입니다.

Sep 21 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:dev 10.236.17.226/10.238.17.226(lcm 드라이버 번호 = 129)에서 하트비트 48개 중 1개를 놓쳤습니다.

Sep 21 11:06:57 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:dev 10.236.17.226/10.237.17.226(lcm 드라이버 번호 = 1360929)에서 하트비트 48개 중 1개를 놓쳤습니다.

Sep 21 11:07:02 es1ecc08tev lcm[46893]: INFO:lcm.tli_hand:::005257:dev 10.236.17.226/10.238.17.226(lcm 드라이버 번호 = 129)에서 하트비트 48개 중 2개를 놓쳤습니다.

최대 하트비트 수에 도달하면 장애 조치가 시작됩니다.

Sep 21 11:10:49 es6ecc08tev lcm[9416]: INFO:lcm.tli_hand:::005257:dev 10.237.17.226/10.236.17.226(lcm 드라이버 번호 = 71)에서 하트비트 47/48이 누락되었습니다.

9월 21일 11:10:49 es6ecc08tev eventslcm[47082]: WARN:lcd.net:::004258:10.237.17.226/10.236.17.226에 의한 es1ecc08tev와의 통신 실패

Sep 21 11:10:49 es6ecc08tev eventslcm[47082]: WARN:lcd.net:::004261:COMMUNICATIONS 시스템 “es1ecc08tev”에서 장애 조치가 시작됩니다.

9월 21일 11:10:49 es6ecc08tev lifekeeper[47121]: NOTIFY:event.comm_down:::010466:통신 es1ecc08tev 실패

/var/log/메시지

이 Linux 생성 파일에는 일반적으로 시스템에서 실행되는 다양한 프로세스 및 서비스에 의해 생성된 시스템 메시지가 포함되어 있습니다. 이러한 메시지에는 다음이 포함될 수 있습니다.

시스템 부팅 메시지: 커널 메시지와 systemd 또는 기타 init 시스템의 메시지를 포함하여 시스템 부팅 프로세스에 대한 정보입니다.

서비스 시작 및 종료 메시지: 프로세스 중에 발생한 오류나 경고를 포함하여 서비스가 시작되거나 중지되는 시기를 나타내는 메시지입니다.

커널 메시지: 하드웨어 감지, 장치 초기화, 커널 오류 또는 경고를 포함한 Linux 커널 작동에 대한 정보입니다.

네트워크 관련 메시지: 네트워크 연결, 방화벽 활동 및 네트워크 구성 변경에 대한 정보입니다.

시스템 성능 정보: CPU 사용량, 메모리 사용량, 디스크 I/O 통계 등 시스템 성능 모니터링과 관련된 메시지입니다.

SIOS 고가용성 및 재해 복구

SIOS Technology Corporation이 제공하는고가용성그리고재해 복구가장 중요한 애플리케이션에 대한 클러스터 관리를 통해 IT 인프라를 보호하고 최적화하는 제품입니다.오늘 저희에게 연락하십시오자세한 내용은.

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

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

  • « Previous Page
  • 1
  • …
  • 22
  • 23
  • 24
  • 25
  • 26
  • …
  • 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