어디에서나 높은 가용성과 재해 복구: 일반적인 개념부터 솔루션 개발까지

관련 블로그 / 배경 지식 추천 자료

이 블로그에서는 LifeKeeper 리소스 계층 구조 프레임워크와 LifeKeeper 클러스터링에 대한 기본적인 이해가 있다고 가정합니다. 이러한 주제에 대한 배경 지식은 아래 링크된 블로그에서 확인할 수 있습니다. 또한, 이 블로그는 LifeKeeper 내의 “Quick Service Protection Application Recovery Kit”(QSP ARK)을 사용하여 가능한 사용 사례와 지원되는 보호 메커니즘 간의 격차를 해소하는 한 가지 방법에 대한 이전 블로그(아래 링크 참조)를 기반으로 작성되었습니다.

• 리눅스 클러스터링/윈도우 클러스터링(본 글은 SIOS 글로벌 영업 및 마케팅 부사장인 호글랜드 씨와 SIOS 마케팅 팀이 작성했습니다.)
• 고가용성과 관련된 애플리케이션 인텔리전스(본 글은 SIOS IT 부서의 선임 시스템 엔지니어인 헨드릭스-싱케 여사가 작성했습니다.)
• 자원 관련 조치 및 배경 정보범용 애플리케이션 복구 키트(본 글은 버밍엄 씨(선임 기술 전도사)께서 작성해 주셨습니다.)
• GenApp과 QSP 중 선택하기: 핵심 애플리케이션에 최적화된 고가용성 솔루션 구축(본 글은 SIOS IT 부서의 선임 시스템 엔지니어인 헨드릭스-싱케 여사가 작성했습니다.)

하지만 이 블로그에서는 QSP ARK가 특정 애플리케이션 또는 사용 사례에 대한 고가용성 및 재해 복구 요구 사항을 충족할 수 없을 때 사용할 수 있는 옵션에 대해 살펴보겠습니다.

간단한 복습

이 블로그의 이전 부분이 섹션에서는 LifeKeeper를 사용하여 애플리케이션을 보호하기 위한 범용 애플리케이션 복구 키트(GAK)를 생성하기 위해 애플리케이션을 어떻게 이해해야 하는지에 대해 다루었습니다. 1부에서 제시된 애플리케이션 이해의 기초를 LifeKeeper의 범용 애플리케이션 복구 키트 프레임워크에 맞춰 적용합니다.

이번 블로그 시리즈는 이전 편과 함께 읽는 것이 가장 좋으므로, 1편에서 다룬 개념들을 간단히 복습해 보겠습니다.

유용하고 실행 가능한 정보를 얻을 수 있는 가장 간단한 질문을 하세요.

포괄적인 질문에 대한 답을 찾을 때는, 그 질문들을 더 작고 답하기 쉬운 질문들로 나누세요. 그리고 그 작은 질문들을 활용하여 원래의 “포괄적인” 질문에 대한 답을 점진적으로 재구성해 나가세요.

제공된 정보를 활용하세요

사용 가능한 유틸리티와 이러한 유틸리티가 정보를 전달하는 방식을 이해하십시오. “가장 기본적인 질문”에 답하는 데 필요한 정보를 파악하고, 애플리케이션의 API를 통해 제공되는 정보를 활용하여 “가장 기본적인 질문”에 대한 답을 찾는 방법을 결정하십시오.

복습이 끝났으니 이제 LifeKeeper를 본격적으로 살펴볼 차례입니다. 고가용성과 재해 복구는 종종 복잡하게 느껴지지만, 특정 애플리케이션에 대한 이해를 바탕으로 일반 애플리케이션 복구 키트(GARK) 프레임워크를 쉽게 적용할 수 있도록 상당한 노력을 기울였습니다. 이러한 기초 지식을 바탕으로 LifeKeeper처럼 생각하는 방법을 알아보겠습니다.

라이프키퍼처럼 생각하기

영화 ‘프리키 프라이데이’처럼 엄마와 딸의 몸이 바뀌어 서로의 일상을 제대로 알지 못해 어리둥절한 상황을 상상해 보세요. 바뀐 몸은 당신 대신 중요한 시스템 가동 행사에 참여해야 하는데, 핵심 애플리케이션을 실행하고, 제대로 작동하는지 확인하고, 종료하는 방법을 알아야 합니다. 만약 15분이라는 짧은 전화 통화 시간밖에 없다면 어떻게 설명하시겠습니까? 그 사람이 업무를 완수할 수 있도록 어떤 세부 사항을 알려줘야 할까요?

이 시나리오는 다소 인위적이지만, 핵심 리소스 보호 작업을 분석하는 데 매우 유용한 방법입니다. LifeKeeper는 애플리케이션이 단일 시스템에서만 실행되도록 관리하며, LifeKeeper 리소스 계층 구조는 리소스가 복원되거나 제거될 때마다 필수 애플리케이션 및 시스템 리소스가 올바른 순서로 처리되도록 보장합니다. 결과적으로 LifeKeeper를 통해 개발자는 일반 애플리케이션 리소스로 보호되는 애플리케이션에 대한 작업을 단일 시스템이라는 맥락에서 이해할 수 있습니다. 애플리케이션 시작, 중지 또는 쿼리 작업을 수행하는 프로세스를 핵심적인 부분으로 단순화하는 것이 일반 애플리케이션 작업 스크립트가 수행해야 할 작업을 정의하는 첫 번째 단계입니다. 위 전략에 따라 시작, 중지 및 쿼리를 정의하면 리소스 작업은 다음과 같이 일대일로 연결됩니다.

• 복원 작업: 애플리케이션 시작
• 제거 작업: 애플리케이션 중지
• 퀵체크 액션: 문의 애플리케이션
  • 메모QuickCheck 작업은 일반 애플리케이션 리소스에 대해 선택 사항이며, QuickCheck 작업이 정의되지 않은 경우 모니터링이 수행되지 않습니다. 그러나 고가용성 및 재해 복구 구현에 최상의 결과를 얻으려면 정기적인 애플리케이션 모니터링을 적극 권장합니다!
• 지역 복구 조치: 애플리케이션 중지 및 애플리케이션 시작(순서대로)
  • 메모로컬 복구 작업은 일반 애플리케이션 리소스에 대해 선택 사항입니다. 로컬 복구가 정의되지 않은 경우, 일반 애플리케이션 리소스는 오류가 감지된 시스템에서 자체 복구를 위해 재시작을 시도하지 않고, 대신 오류가 발생한 시스템에서 중지되며 애플리케이션의 전체 계층 구조가 대기 시스템으로 마이그레이션됩니다.

LifeKeeper는 위에서 설명한 작업을 수행하기 위해 실행 중인 애플리케이션에 대한 특정 세부 정보를 알아야 할 때가 있습니다. 일반 애플리케이션 리소스를 포함한 모든 LifeKeeper 리소스에는 “리소스 정보 필드”가 있으며, 이 필드는 리소스 작업 중에 사용할 정보를 작업 스크립트에 제공하는 역할을 합니다. 정보 필드에 포함된 리소스 정보는 리소스 확장 시 각 시스템에 대해 독립적으로 구성할 수 있으므로 리소스 작업이 수행되는 시스템에 특정한 정보를 활용할 수 있습니다. LifeKeeper는 또한 리소스 정보를 쉽게 가져오거나 설정할 수 있는 명령줄 유틸리티를 제공합니다.

영화 “프리키 프라이데이”의 예시를 다시 떠올려보면, 서로 역할을 바꾼 사람에게 어떤 정보를 알려줘야 할까요? 예를 들어 애플리케이션 파일의 키 경로, 명령 인수에 대한 특정 설정/값, 그리고 이와 유사한 세부 정보들을 생각해 보세요. 정보 필드는 애플리케이션에 대한 다른 세부 정보를 파악하는 데 필요한 정보를 입력하기에 적합한 곳입니다. 또한, 설정값, 명령 인수 또는 다른 방법으로는 알아낼 수 없는 값들을 입력하기에도 좋은 곳입니다. LifeKeeper의 관례에 따라 정보 필드는 리소스의 수명 주기 동안 거의 변경되지 않는다는 점을 고려해 볼 가치가 있습니다. 리소스의 수명 주기 동안 변경되는 정보는 이 필드의 손상을 방지하기 위해 리소스 정보에서 제외하고, 대신 LifeKeeper 리소스의 액션 스크립트에서 프로그래밍 방식으로 가져오거나 액션 스크립트에서 호출할 수 있는 “헬퍼” 스크립트를 통해 가져오는 것이 좋습니다.

추가적인 지원으로, LifeKeeper는 범용 애플리케이션 개발을 위한 템플릿 스크립트를 제공합니다. 이러한 스크립트는 범용 애플리케이션의 액션 스크립트를 작성하는 데 훌륭한 출발점이 됩니다. 특정 리소스에 대한 액션을 호출할 때 LifeKeeper가 사용할 입력 인수를 미리 준비해 두었기 때문입니다. 결과적으로, 이러한 정보는 리소스 액션 스크립트에서도 활용할 수 있게 됩니다.

결론

LifeKeeper는 다양한 애플리케이션 보호 방법을 제공합니다. 하지만 일부 애플리케이션은 LifeKeeper 애플리케이션 복구 키트(ARC)에서 제공하는 범위를 넘어서는 요구 사항을 가지고 있습니다. 이러한 경우에도 고가용성 및 재해 복구(HAR) 보호는 가능하며, 생각보다 간단하게 구현할 수 있습니다. 범용 애플리케이션(Generic Application)은 조직에서 주저할 대상이 아니라, LifeKeeper가 제공하는 강력한 도구 중 하나로, 환경의 고가용성 및 재해 복구 기능을 향상시키는 데 활용될 수 있습니다. 범용 애플리케이션 프레임워크는 접근성과 다용성을 고려하여 설계되었습니다. 만약 조직에서 범용 애플리케이션 복구 키트를 자체적으로 개발할 여력이 없다면, SIOS는 전문 서비스(Professional Services)를 통해 SIOS 엔지니어가 요구 사항을 조율하고 조직을 대신하여 범용 애플리케이션 복구 키트를 개발해 드립니다. 지속적인 지원이 필요한 경우, SIOS 전문 서비스는 SIOS 전문 서비스에서 개발한 범용 애플리케이션에 대한 지원을 포함하여 일반 제품 지원을 확장하는 서비스도 제공합니다. 조직의 비즈니스 핵심 애플리케이션을 보호하는 데 필요한 진입 장벽은 끊임없이 낮아지고 있으며, SIOS Protection Suite for Linux or Windows는 보호되지 않은 애플리케이션을 과거의 유물로 만드는 데 앞장서고자 합니다.

모든 애플리케이션이 표준 고가용성 모델에 적합한 것은 아닙니다. SIOS는 비즈니스 핵심 워크로드에 적합한 LifeKeeper 솔루션을 설계하고 구현하는 데 도움을 드릴 수 있습니다.데모를 요청하세요오늘.

저자: SIOS Technology Corp.의 지원 엔지니어인 필립 메리

허가를 받아 재게재되었습니다.SIOS

단일 장애 지점 제거

기업 IT 분야에서 “단일 장애점(SPOF)”이라는 단어는 시스템 관리자에게 밤잠을 설치게 할 만큼 무서운 말입니다. SPOF는 서버, 네트워크 스위치, 스토리지 어레이 등 인프라 구성 요소 중 하나라도 고장 나면 전체 시스템이 다운되는 현상을 의미합니다. 기업들이 점점 더 요구함에 따라 이러한 문제는 더욱 심각해지고 있습니다.99.99% (또는 그 이상) 가동 시간따라서 이러한 취약점을 식별하고 제거하는 것은 더 이상 선택 사항이 아니라 필수적인 요구 사항입니다.

인프라를 완벽하게 보호하려면 고가용성(HA)과 다음을 결합하는 것이 좋습니다.데이터 복제이 솔루션은 단일 장애점(SPOF)을 제거하고 지속적인 운영을 보장하는 강력한 엔터프라이즈급 솔루션을 제공합니다.

클러스터링을 활용하여 단일 장애점(SPOF)을 제거하는 방법

고가용성의 핵심은 클러스터링 개념입니다. 클러스터는 높은 신뢰성을 갖춘 서비스를 제공하기 위해 함께 작동하도록 구성된 독립적인 서버(노드) 그룹입니다. 이러한 서비스는 사용자 정의 애플리케이션부터 파일 공유에 이르기까지 무엇이든 될 수 있습니다.

일반적인 고가용성(HA) 클러스터에서는 하나의 노드가 서비스를 적극적으로 호스팅하고 하나 이상의 노드가 대기 상태로 유지됩니다. SIOS LifeKeeper와 같은 클러스터 관리 소프트웨어는 활성 노드의 상태를 지속적으로 모니터링하여 서비스를 제대로 호스팅할 수 있도록 합니다.

기본 노드에서 심각한 오류가 감지되면클러스터 소프트웨어장애 조치를 자동으로 오케스트레이션합니다. 애플리케이션 서비스, IP 주소, 스토리지 및 종속성을 정상적인 대기 노드로 전환합니다. 이 프로세스를 자동화함으로써 개별 서버가 단일 장애 지점이 되지 않아 서비스 중단을 최소화하면서 서비스 연속성을 보장합니다.

SAN 단일 장애점 제거

기존 클러스터링 방식은 일반적으로 모든 노드에서 데이터에 대한 공유 액세스를 제공하기 위해 SAN(Storage Area Network)에 의존합니다. 그러나 이러한 설계에는 치명적인 취약점이 있는데, 바로 SAN이 단일 장애 지점이 된다는 점입니다. 공유 스토리지 어레이에 장애가 발생하면 개별 노드는 정상적으로 작동하더라도 전체 클러스터가 작동 불능 상태가 됩니다.

공유 스토리지 SPOF(단일 장애점)를 제거하기 위해 관리자는 데이터 복제를 사용하여 “SAN이 없는” 클러스터를 생성합니다. SAN 대신 각 노드는 자체 로컬 연결 스토리지를 사용합니다. 소프트웨어는 다음과 같습니다.SIOS 데이터키퍼운영 체제 수준에서 작동하며 활성 노드의 스토리지에서 대기 노드의 스토리지로 블록 수준의 지속적인 복제를 수행합니다.

데이터가 실시간으로 지속적으로 복제 및 미러링되므로 대기 노드는 로컬 저장소에 최신 데이터를 저장하여 언제든지 즉시 인계받을 준비가 되어 있습니다.

다양한 통신 경로 및 정족수/증인 솔루션

클러스터가 안전하게 작동하려면 노드들은 서로의 상태를 확인하기 위해 지속적으로 통신해야 합니다. 이를 위해 노드들은 “하트비트”라고 불리는 작고 빈번한 데이터 패킷을 교환하는데, 이 패킷은 노드가 살아있고 정상 작동 중임을 나타냅니다.

대기 노드가 하트비트를 수신하지 못하면 기본 노드가 다운되었다고 판단하고 애플리케이션을 온라인 상태로 전환하려고 시도할 수 있습니다. 하지만 기본 노드가 실제로 여전히 실행 중인 경우, 두 노드가 동시에 데이터를 쓰려고 시도하는 상황이 발생하게 되는데, 이를 “대기 노드 충돌(Default Node Response)”이라고 합니다.분할뇌.“이를 방지하려면 클러스터에 쿼럼 또는 위트니 솔루션을 항상 구성해야 합니다. 이는 어떤 노드가 활성 워크로드를 안전하게 소유해야 하는지 결정하는 데 있어 결정자 역할을 합니다.

또한, 네트워크 인프라가 단일 장애점(SPOF)이 되는 것을 방지하기 위해 복원력이 뛰어난 클러스터 아키텍처는 여러 통신 경로를 필요로 합니다. 노드들이 서로 통신할 수 있는 다양한 경로를 확보함으로써, 단일 네트워크 스위치의 고장이나 케이블 단선으로 인해 클러스터의 로직이 중단되는 것을 방지할 수 있습니다.

SIOS를 사용하여 체계적으로 단일 장애점(SPOF)을 찾아 제거하세요

진정으로 가용성이 높은 환경을 구축하려면 최악의 시나리오를 고려하여 아키텍처를 검토해야 합니다. SIOS LifeKeeper의 지능형 애플리케이션 모니터링 기능과 SIOS DataKeeper의 강력한 SAN리스 복제 기능을 결합하면 단일 장애 지점을 체계적으로 찾아 제거할 수 있습니다.

작가트레이 아이작, SIOS 선임 제품 지원 엔지니어

허가를 받아 재게재되었습니다.SIOS

LifeKeeper 고가용성 및 재해 복구를 위한 범용 애플리케이션

비즈니스 핵심 애플리케이션 보호를 위한 성공의 열쇠

고가용성 및 재해 복구는 광범위한 사용 사례를 포괄해야 합니다. 사용 사례는 조직의 수만큼이나 많으며, 단일 솔루션의 역량을 훨씬 뛰어넘습니다.고가용성그리고재해 복구모든 시나리오에 즉시 사용 가능한 지원을 제공하는 솔루션입니다. 일반적인 애플리케이션에는 다양한 고가용성 및 재해 복구 솔루션이 있지만, 특정 사용 사례에서는 비즈니스 핵심 애플리케이션을 보호하는 데 사용할 수 있는 솔루션 선택이 제한적입니다.

물론 LifeKeeper가 모든 사용 사례를 기본적으로 지원할 수는 없습니다. 하지만 LifeKeeper는 이러한 한계를 극복하기 위해 다양한 사용 사례에 적용할 수 있는 다재다능하고 유연한 프레임워크를 제공합니다. 강력한 기능을 갖춘 이 프레임워크는 외부인에게는 복잡해 보일 수 있습니다. 이 블로그는 특정 사용 사례에 맞는 범용 애플리케이션 복구 키트를 구상하는 데 도움이 되는 정보를 제공합니다.

관련 블로그 및 배경 자료 추천

이 블로그에서는 LifeKeeper 리소스 계층 구조 프레임워크와 LifeKeeper 클러스터링에 대한 기본적인 이해가 있다고 가정합니다. 이러한 주제에 대한 배경 지식은 아래 링크된 블로그에서 확인할 수 있습니다. 또한, 이 블로그는 LifeKeeper 내의 “Quick Service Protection Application Recovery Kit”(QSP ARK)을 사용하여 가능한 사용 사례와 지원되는 보호 메커니즘 간의 격차를 해소하는 한 가지 방법에 대한 이전 블로그(아래 링크 참조)를 기반으로 작성되었습니다.

• 리눅스 클러스터링/윈도우 클러스터링(본 글은 SIOS 글로벌 영업 및 마케팅 부사장인 호글랜드 씨와 SIOS 마케팅 팀이 작성했습니다.)

• 고가용성과 관련된 애플리케이션 인텔리전스(본 글은 SIOS의 선임 소프트웨어 엔지니어인 헨드릭스-싱케 씨가 작성했습니다.)
• 자원 관련 조치 및 배경 정보범용 애플리케이션 복구 키트(본 글은 버밍엄 씨(선임 기술 전도사)께서 작성해 주셨습니다.)
• GenApp과 QSP 중 선택하기: 핵심 애플리케이션에 최적화된 고가용성 솔루션 구축(본 글은 SIOS의 선임 소프트웨어 엔지니어인 헨드릭스-싱케 씨가 작성했습니다.)

하지만 이 블로그에서는 QSP ARK가 특정 애플리케이션 또는 사용 사례에 대한 고가용성 및 재해 복구 요구 사항을 충족할 수 없을 때 사용할 수 있는 옵션에 대해 살펴보겠습니다.

응용 프로그램의 개념화 및 접근 방식 정의

애플리케이션 상태에 대한 가장 작은 질문을 던지다

시스템 관리와 ​​소프트웨어 엔지니어링은 모두 미묘한 차이가 많은 분야입니다. 하나의 질문에는 너무나 많은 요소가 얽혀 있어 간단하고 명확한 답을 얻기가 어려울 수 있습니다. 대화에서는 이러한 어려움을 쉽게 해결할 수 있지만, 코드에서는 복잡한 질문에 대한 답을 찾기가 어렵습니다. “가장 작은” 질문을 한다는 것은 가능한 한 가장 작은 요소에 초점을 맞춰 질문을 하고, 동시에 명확한 기준을 충족하는 답을 찾는 방법입니다.

“애플리케이션이 실행 중인가요?” 이 질문은 상당히 까다롭고, 자세한 답변이 필요할 수 있습니다. 예를 들어, “네, 애플리케이션은 실행 중이지만 응답하지 않습니다.” 또는 “네, 애플리케이션은 실행 중이지만, 말씀하신 시스템이 아닌 다른 시스템에서 실행되고 있습니다.”와 같이 답변 기준이 모호하고 미묘한 차이가 있을 수 있습니다. 개발자들은 이러한 세부적인 사항까지 일일이 처리하고 싶어 하지 않습니다.

“애플리케이션 프로세스가 실행 중이며, 애플리케이션이 쿼리에 적극적으로 응답하고 있습니까?”

말하기는 좀 길지만, 더 작은 질문입니다. 이 질문은 답이 ‘예’ 또는 ‘아니오’가 되는 조건을 명확하게 정의합니다. 이러한 변화는 개선된 것이지만, 아직 ‘가장 작은’ 질문은 아닙니다. 이전 질문은 “X와 Y가 모두 참인가?”라는 함정에 빠지기 쉽습니다. ‘예’ 또는 ‘아니오’라는 답변으로는 X와 Y의 진위를 독립적으로 판단할 수 있는 충분한 정보를 제공할 수 없습니다. 가장 작은 질문은 구체성을 요구하며, 전체의 가장 작은 요소의 상태를 완벽하게 파악할 수 있도록 해야 합니다. “애플리케이션 프로세스가 원하는 시스템에서 실행 중인가?” 이것이 바로 작은 질문이며, 이 경우 가장 작은 질문입니다. 물론 ‘가장 작은’ 질문은 여러 개일 수 있습니다. 이 예시에서는 “애플리케이션이 쿼리에 응답하는가?”도 가장 작은 질문에 해당합니다.

질문은 거의 무한히 세분화될 수 있지만, 한계는 있습니다. “가장 간단한 질문”이라는 말에는 “유용하고 실행 가능한 정보를 제공하는 가장 간단한 질문”이라는 의미가 내포되어 있습니다. “필라델피아행 기차를 타고 있나요?”라는 질문만으로도 충분합니다. “필라델피아행 기차를 타고 있고, 필라델피아는 어느 방향인가요?”라고 묻는 것은 더 많은 정보를 제공하지만, 실질적인 행동으로 이어지지는 않습니다. 기차의 방향을 바꿀 수는 없기 때문입니다. 하지만 “필라델피아행 기차를 타고 있나요?”라는 질문에 대한 답을 통해 상사에게 지각 사실을 알리기 위해 회사에 전화해야 할지 여부를 알 수 있습니다.

이 예시에서는 명확하지만, 일반적인 애플리케이션을 개발할 때는 그렇지 않습니다. 일반적인 애플리케이션을 보호하는 과정 전반에 걸쳐 더 큰 그림을 염두에 두어야 합니다. 이는 다른 모든 것과 마찬가지로 기술입니다. 연습과 협업을 통해 어떤 질문이 가장 기본적인 질문인지, 그리고 더 이상의 세부적인 설명이 더 이상 유용한 정보를 제공하지 않는 시점을 판단하는 능력이 향상됩니다.

포괄적인 질문들을 더 작고 구체적이며 개별 요소에 대한 구체적인 질문들로 세분화한 것이 범용 애플리케이션 복구 키트(GAK)의 기반입니다. 각 “핵심 질문”은 관련된 각 요소에 대해 제공된 답변들을 종합하여 해결할 수 있습니다.

질문을 가장 작은 요소로 나누면 전달해야 할 정보가 훨씬 명확해집니다. 필요한 정보를 파악했다면, 범용 애플리케이션 복구 키트를 개발하는 나머지 작업은 제공된 정보에서 필요한 정보를 어떻게 추출하느냐의 문제입니다. 주어진 정보를 최대한 활용해야 합니다.

애플리케이션 API 및 LifeKeeper API 활용

대부분의 애플리케이션은 정보를 표시하거나 애플리케이션에 발생한 변경 사항을 보여주기 위해 그래픽 사용자 인터페이스(GUI)를 제공합니다. 이는 사람이 직접 사용할 때는 매우 유용하지만, 애플리케이션이 관리를 담당할 때는 그다지 효과적이지 않습니다. GUI는 사람이 사용하기 위한 것이며, 애플리케이션은 (대규모 프로그래밍 작업과 불필요한 복잡성을 피하기 위해) 사람이 사용하는 방식처럼 다른 애플리케이션의 GUI와 상호 작용하도록 설계되지 않았습니다. LifeKeeper와 일반 애플리케이션 리소스의 경우, 일반 애플리케이션 복구 키트의 액션 스크립트와 보호 대상 애플리케이션 간의 정보 교환은 애플리케이션 프로그래밍 인터페이스(API)를 통해 이루어져야 합니다.

LifeKeeper는 LifeKeeper, 계층 구조 및 계층 구조 내 리소스와 상호 작용하기 위한 자체 API를 제공합니다. LifeKeeper API의 경우, 제품에 포함된 명령줄 유틸리티가 일반 애플리케이션에서 사용하기 가장 쉽습니다. 일반적으로 LifeKeeper 제품 설명서에 설명된 명령줄 유틸리티만 사용하는 것이 좋습니다.리눅스 명령어 설명서/윈도우 명령어 설명서)를 사용해야 합니다. 이러한 권장 사항에도 불구하고, 의도치 않은 동작이 발생하지 않도록 이러한 명령은 신중하게, 그리고 세심하게 사용해야 합니다.

물론, LifeKeeper는 범용 애플리케이션 복구 키트의 유일한 요소는 아닙니다. 보호 대상 애플리케이션은 액션 스크립트가 원하는 결과를 얻기 위해 해당 애플리케이션의 API를 활용할 수 있도록 API를 제공해야 합니다. 범용 애플리케이션 복구 키트를 개발하려면 보호 대상 애플리케이션의 API와 해당 API를 키트를 구성하는 액션 스크립트 내에서 사용하는 방법에 대한 지식이 필요합니다.

복구 스크립트에서 반환 코드 및 출력 스트림 사용

LifeKeeper용 API든 보호된 애플리케이션이든, 정보는 주로 두 가지 방식으로 출력됩니다.

• 반환 코드
• 출력 스트림(때때로 “STDOUT/STDERR 출력” 또는 “터미널 출력”이라고도 함)

반환 코드는 성공 또는 실패 여부를 판단하는 데 어떻게 도움이 될까요?

반환 코드는 넓은 의미에서 유틸리티의 성공 여부를 빠르게 확인할 수 있는 방법을 제공합니다. 일반적으로 (셸 환경에서) 반환 코드 0은 성공을 나타내고, 0이 아닌 반환 코드는 실패를 나타냅니다.

애플리케이션에 따라 반환 코드의 정확한 값은 발생한 오류에 대한 더 많은 정보를 제공할 수 있습니다. 종종 애플리케이션 API를 통해 수행된 작업의 결과는 반환 코드를 확인하는 것만으로 추측할 수 있습니다.

좀 더 미묘한 경우에는 반환 코드가 단순히 애플리케이션 API 호출 후 프로그램이 어떤 조치를 취해야 하는지 알려주는 데 사용될 수 있습니다. 반환 코드는 특히 특정 요소의 상태와 관련된 유틸리티를 다룰 때 유용합니다.

출력 스트림을 통해 더욱 자세한 애플리케이션 정보를 얻는 방법

출력 스트림은 프로그램에서 사용하기에는 다소 복잡하지만, 정보 교환이나 결과 검증에 필요한 경우가 있습니다. 예를 들어, 시스템 호스트 이름을 가져오는 유틸리티를 실행할 때 반환 코드만으로는 호스트 이름을 알 수 없습니다. 유틸리티가 호스트 이름을 성공적으로 가져왔는지 여부만 확인할 수 있습니다. 어떤 경우에는 API 유틸리티가 요청된 정보를 얻었을 때 성공 반환 코드를 반환하지만, 해당 정보의 유효성은 상황에 따라 평가해야 합니다.

반환 코드든 출력 스트림이든, 범용 애플리케이션을 개발하려면 주어진 정보를 최대한 활용해야 합니다. 리소스 작업(다음 섹션에서 설명)을 수행하거나 애플리케이션 또는 LifeKeeper 리소스에 대한 정보를 확인하는 방법을 생각할 때, GUI 인터페이스가 아닌 반환 코드와 출력 스트림의 관점에서 생각해 보세요. 마치 전화로 정보를 전달하는 것처럼 생각하면 이해하기 쉽습니다. 즉, 유틸리티의 입력과 출력이 입력으로 제공되거나 출력으로 보고되는 그대로 전달될 때 정보가 가장 잘 전달되고, 작업이 가장 잘 정의되며, 시나리오가 가장 잘 처리됩니다.

범용 애플리케이션 보호를 위한 기반 구축

이 섹션에서는 전략을 매우 개념적인 수준으로 다루었습니다. 이러한 전략은 애플리케이션에 대한 질문과 실행된 조치에 대한 응답을 통해 애플리케이션을 분석하는 기초를 제공합니다. 앞으로는 LifeKeeper와 일반 애플리케이션 복구 키트 생성 프로세스에 더욱 특화된 접근 방식을 사용할 것입니다. 이러한 전략은 다른 기술과 마찬가지로 연습을 통해 발전시켜 나갈 것입니다. 기술 커뮤니케이션, 절차서 작성 등 어떤 분야에서든 이러한 개념화 전략을 연습하면 단기적으로는 물론 장기적으로도 도움이 될 것입니다.

표준 고가용성 모델에 맞지 않는 비즈니스 핵심 애플리케이션 보호에 도움이 필요하신가요? SIOS는 고객 환경을 평가하고 적합한 LifeKeeper 접근 방식을 결정하는 데 도움을 드릴 수 있습니다.데모를 요청하세요오늘.

저자: 필립 메리, SIOS 테크놀로지 사의 L3 지원 엔지니어

허가를 받아 재게재되었습니다.SIOS

SIOS 엔터프라이즈 지원 가이드: 플랜 보장 내용

SIOS 엔터프라이즈 지원 플랜에는 무엇이 포함되어 있나요?

다음은 엔터프라이즈급 지원에서 포함되는 내용과 포함되지 않는 내용, 그리고 세 가지 일반적인 시나리오를 기반으로 추가 정보를 얻을 수 있는 곳에 대한 몇 가지 간단한 팁입니다.

중요 시스템 다운타임 발생 시 24시간 연중무휴 지원

시나리오 1: 근무 시간 외 시스템 장애 발생

조앤 팀: 일요일 저녁 7시(미국 동부시간). SIOS LifeKeeper 클러스터 노드 간의 정기적인 전환 작업은 간단했어야 했습니다. 하지만 예상치 못한 문제가 발생하여 전환이 실패했습니다. 팀원들이 문제 해결을 위해 모든 노력을 기울였지만, 클러스터는 여전히 다운된 상태입니다. 조앤은 도움이 필요하지만, SIOS 기술 지원 플랜에 주말 지원이 포함되는지, 그리고 담당자와 통화하는 데 얼마나 걸릴지 확신할 수 없습니다.

사고 발생 전에 엔터프라이즈급 지원을 구매(또는 갱신)한 고객은 연중무휴 24시간 지원을 받을 수 있습니다. 여기에는 주말과 공휴일을 포함한 긴급 상황 대응 지원이 포함됩니다. 긴급 상황이란 SIOS 프로그램을 사용하여 고객 데이터에 접근할 수 없는 운영 시스템 또는 애플리케이션의 다운을 의미합니다. 정상적인 운영이 중단되어 운영 데이터 접근이 불가능해지는 모든 우선순위 1(긴급) 문제에 대해 SIOS는 2시간 이내에 대응합니다.

Joan에게 유효한 엔터프라이즈 지원이 있다면 SIOS 지원팀에 연락할 수 있으며, 근무 시간 외 문제도 지원받을 수 있습니다.

설치 및 구성 지원

시나리오 2: 설치 지원 필요

스콧 팀: 목요일 오후 4시(미국 동부시간). 새로운 인프라 프로젝트에 대한 승인이 완료되었으며, 여기에는 핵심 애플리케이션과 데이터에 필요한 고가용성(HA) 구성도 포함됩니다. 프로젝트 착수 회의에서 이해관계자들이 시스템 가동 날짜를 변경했기 때문에, 서비스 중단을 방지하기 위해 시스템을 신속하게 설치하고 구성해야 합니다. 스콧 팀은 애플리케이션과 서버 구성 방법은 알고 있지만, HA 솔루션을 정확하게 설치했는지 다시 한번 확인하고 싶어 합니다. 도움이 필요하지만, 스콧은 현재 지원 플랜에 설치 오류에 대한 지원이 포함되는지 확신하지 못하고 있습니다.

스콧의 팀은 현재 구축 단계에 있으므로, 새로운 인프라 프로젝트에는 아직 검증되지 않았거나 성공적으로 운영 환경에 배포되지 않은 시스템이 포함됩니다. 스콧의 팀이 유효한 SIOS 엔터프라이즈급 지원을 받고 있다면, SIOS 제품 문서와 설치 지침에 접근할 수 있습니다. 하지만 설치 및 구성 지원은 엔터프라이즈 지원 범위에 포함되지 않으므로, SIOS 영업 담당자에게 연락하여 유료 전문 서비스 설치 계약을 체결할 수 있습니다. 이 계약을 통해 스콧의 팀은 클러스터를 제대로 설치, 구성 및 검증하는 데 필요한 지원을 받을 수 있습니다. SIOS는 다양한 기능을 제공합니다.전문 서비스고객이 고가용성(HA) 환경을 신속하고 비용 효율적으로 구현, 관리 및 유지할 수 있도록 설계되었습니다.

장애 조치 후 근본 원인 분석(RCA)

시나리오 3: 장애 조치 후 근본 원인 분석(RCA) 지원

아몰의 팀: 화요일 새벽 2시(미국 동부시간). AjaxBjax Corp.의 전체 애플리케이션 팀에 알림이 전송되었습니다. 회사에서 가장 중요한 애플리케이션 시스템을 보호하는 클러스터가 페일오버를 진행 중이라는 내용입니다. 아몰은 애플리케이션 대시보드를 확인하여 페일오버가 성공적으로 완료되었고 모든 애플리케이션이 정상적으로 작동하고 있음을 확인했습니다. 하지만 아몰은 경영진이 몇 가지 설명과 확답을 요구할 것이라는 것을 알고 있습니다. 모든 애플리케이션 서비스가 정상적으로 작동하는지 확인하고 싶지만, 회사의 지원 계획에 이러한 상황이 포함되는지 확신할 수 없습니다.

아몰의 팀은 근본 원인 분석(RCA)을 통해 시스템이 계속 정상적으로 작동할 것이라는 확신을 얻고자 합니다. 아몰의 데이터는 접근 가능하며 애플리케이션은 완벽하게 작동합니다. 그의 시스템은 심각한 장애가 발생한 운영 서버도 아니고, P1 등급의 문제도 아닙니다. 하지만 AjaxBjax Corp가 해당 클러스터에 대한 유효한 엔터프라이즈 지원을 보유하고 있다면, 월요일부터 금요일까지 미국 동부 시간 기준으로 24시간 내내 SIOS 지원팀의 도움을 받아 RCA 문제를 해결할 수 있습니다. 아몰의 새벽 2시 전화는 숙련된 SIOS 지원 센터로 연결되어 해당 팀이 아몰과 함께 문제 해결을 시작할 것입니다.

SIOS 지원팀에 문의하기 관련 추가 질문

아몰과 조안은 기업 지원에 포함된 지원 핫라인(미국: 877.457.5113, 국제: +1.803.808.4270)을 통해 지원을 받을 수 있었습니다. 스콧은 지원팀이 아닌 구성 및 설치 지원 서비스를 구매하여 필요한 도움을 받았습니다. 그렇다면 스콧, 아몰, 조안을 비롯한 다른 사용자들은 어떻게 지원 수준과 지원 세부 정보를 확인할 수 있을까요? 또는 제품이 유지 보수 또는 연장 지원 단계에 도달했는지 여부는 어디에서 알 수 있을까요?

지원 계약에 대한 추가 정보가 필요하시면 모든 주문에 포함된 SIOS 기술 지원 계약(TSA)을 참조하십시오. TSA는 당사 웹사이트에서도 편리하게 확인하실 수 있습니다.다운로드 사이트해당 서비스는 SIOS 지원팀으로 이메일을 통해 요청할 수 있습니다.support@us.sios.com또한 제품 일정 및 지원 등급 정보는 온라인에서 확인할 수 있습니다.제품 수명 주기페이지.

이미 자신의 플랜에 포함된 내용을 알고 있지만 문제 해결, 일반적인 질문에 대한 답변, 근본 원인 분석, 최신 소프트웨어 또는 추가 정보에 대한 도움이 필요한 고객은 새 문의를 통해 지원을 요청할 수 있습니다.지원 포털웹사이트 또는 지원 메일함으로 이메일을 보내주세요.support@us.sios.com사건이 접수되면 담당 팀에서 신속한 답변과 해결책을 제공하기 위해 노력할 것입니다.

저자: 카시우스 루, 고객 경험 담당 부사장

허가를 받아 재게재되었습니다.SIOS