Linux 클러스터용 SIOS LifeKeeper 관리

Linux 클러스터용 SIOS LifeKeeper 관리

아기를 안고 미니밴 밖에 서서 기저귀 가방을 꺼내려는 순간, 빨간색 줄무늬가 있는 커다란 검은색 밴이 옆에 멈춰 섭니다. 밴 문이 천천히 열리자 다양한 사람들이 모습을 드러냅니다. 위풍당당한 남자가 차에서 내립니다. 그의 모히칸 헤어스타일은 하늘을 찌를 듯 뻗쳐 있고, 목에 걸린 금 목걸이만큼이나 강렬하고 냉철한 분위기가 풍깁니다. 노련한 베테랑이 차에서 내려 당신에게 중요한 작전에 투입되었다고 말합니다.

당신이 가장 좋아하는 밴드의 특별 리허설에 맨 앞줄 중앙 왼쪽 자리에 앉아 있다고 상상해 보세요. 밴드가 좋아하는 히트곡들을 연달아 연주하는 것을 들으며, 에어 기타를 치듯 신나게 연주합니다. 완벽한 리듬에 맞춰 의자와 다리를 번갈아 두드리며 드럼 리프를 흉내 내기도 합니다. 그러다 버려진 빅 걸프 음료수 병에서 빨대 두 개를 주워 드럼 솔로를 망쳐버리죠. 오랫동안 기다려온 순간, 드디어 매진된 공연장의 관객석에 앉게 되었는데, 갑자기 드러머가 무대에서 뛰쳐나가고, 당황한 매니저가 당신을 가리키며 무대 위로 올라오라고 합니다.

그레이트 데인 종인 카를로스는 빅 보이즈 케넬 클럽에서 최고의 개로 꼽히는 유력한 우승 후보입니다. 직장 동료들을 통해 대형견 애호가들 사이에서만 카를로스에 대한 이야기를 들어봤을 뿐이지만, 오늘은 카를로스의 전혀 다른 모습을 보게 됩니다. 사실, 카를로스의 모든 면을 보게 되는 거죠. 그의 훈련사가 견인차가 작업용 밴을 끌고 가고 새 렌터카가 올 때까지 기다리는 동안 카를로스를 당신 집 앞에 데려다 놓았거든요. “한 시간 정도 걸릴 거예요.” 훈련사는 당신을 안심시킵니다. 하지만 수백만 달러짜리 최고의 개를 위험으로부터 지키는 건 결코 쉬운 일이 아닙니다.

솔직히 말해서, 오리지널 A팀이나 그와 비슷한 팀이 당신의 미니밴 옆에 나타나 당신을 데려가 국가를 구할 수 있는 극비 임무에 투입할 가능성은 거의 없습니다. 마찬가지로, 당신이 아무리 훌륭한 지미 헨드릭스나 쉴라 E 모창을 한다 해도, 빨대를 사용하든 안 하든, 매진된 공연의 스포트라이트를 받게 될 가능성은 희박합니다. 그리고 카를로스나 다른 인기 있는 개들을 볼 수는 있겠지만, 당신이 그 개의 주인, 훈련사, 또는 심사위원이 아닌 이상, 그들과 단둘이 시간을 보낼 기회는 없을 겁니다. 이러한 시나리오가 실제로 일어날 가능성은 낮지만, 비슷한 위험과 책임, 그리고 중요성을 수반하는 LifeKeeper for Linux 클러스터를 관리해 달라는 요청을 받을 수도 있습니다.

LifeKeeper for Linux 클러스터를 인수인계받았을 때 해야 할 일

많은 기업들이 시스템 다운으로 인한 손실이 시간당 30만 ​​달러에서 수백만 달러에 이른다고 보고합니다. 이러한 재난과 시스템 다운을 방지하고자 하는 기업들은 여러 계층에 걸쳐 이중화된 강력한 아키텍처를 구축하는 경우가 많습니다.

이러한 중복성 외에도 많은 기업에서는 고가용성(HA) 소프트웨어를 배포합니다.Linux용 SIOS LifeKeeperLifeKeeper for Linux는 기업의 핵심 인프라, 애플리케이션 및 데이터베이스에 필수적인 모니터링 및 복구 기능을 제공합니다. 이를 통해 인프라, 애플리케이션, 서비스 및 데이터베이스에 대한 리소스 모니터링 및 복구 기능을 제공하여 비즈니스 연속성을 유지하고 다운타임을 최소화하거나 방지할 수 있습니다. 비록 전문 요원이 탑승한 검은색 밴이 있는 것은 아니지만, 비즈니스 운영에 있어 매우 중요한 역할을 합니다.

그렇다면, 갑자기 수십 가지 버전의 Carlos보다 더 많은 수익을 창출하는 LifeKeeper for Linux(LK-L) 환경의 수석 관리자 또는 단독 운영자가 된다면 어떻게 해야 할까요?

SIOS LifeKeeper for Linux 클러스터를 인수하는 8단계

SIOS LifeKeeper for Linux 클러스터를 인수하기 위한 8가지 핵심 단계는 다음과 같습니다.

1. 기존 운영 매뉴얼을 찾아 검토하십시오.

기존 런북을 찾아보세요. 런북은 이전 관리자가 만든 문서 저장소에 저장되어 있는 경우가 많습니다. 상세한 런북은 클러스터의 구성 및 아키텍처에 대한 정보를 제공하며, 이는 향후 관리 및 운영에 도움이 될 것입니다.

2. 사용 중인 LifeKeeper for Linux 제품 버전을 확인하세요.

제품 버전을 파악하는 것은 클러스터 인수인계에 있어 매우 중요합니다. SIOS는 더욱 풍부한 기능, 보안 업데이트 및 개선 사항을 제공하는 제품 업데이트를 자주 출시합니다. 기존 제품 클러스터를 인수인계할 때는 현재 사용 중인 버전을 알아야 여러 요소를 평가할 수 있습니다.

1. 귀사의 제품은 제품 및 지원 수명 주기에서 어느 단계에 있습니까?
2. 제품의 최신 버전을 사용 중이신가요?
3. 사용하시는 버전 이후로 제품에 어떤 새로운 기능이나 수정 사항이 추가되었나요?
4. 버전별 설명서는 어디에서 찾을 수 있나요?

사용자 인터페이스를 통해 제품 버전을 확인할 수 있습니다. 실행 설명서에 LifeKeeper 버전 9.8.x 이상이 명시되어 있는 경우, https://<서버 이름>:5110 (또는 https://<서버 IP>:5110)을 사용하여 LifeKeeper 웹 관리 콘솔(LKWMC)을 실행할 수 있습니다. 로그인 후 속성을 선택하세요.

속성 페이지가 로드되면 제품 이름 아래 섹션에서 버전 정보를 찾으십시오.

Linux용 LifeKeeper 구버전을 사용 중인 경우,X11 포워딩을 활성화하고 Java UI를 실행합니다.SSH 클라이언트 세션에서 /opt/LifeKeeper/bin/lkGUIapp 명령어를 통해 실행할 수 있습니다.

제품 버전은 다음과 같이 명령줄을 통해서도 확인할 수 있습니다.

# rpm -qi 스틸아이-lk

Java UI를 실행하고 로그인하면 도움말 페이지로 이동할 수 있습니다. 제품 버전을 확인한 후에는 제품 수명 주기 및 버전별 정보를 확인할 수 있습니다.docs.us.sios.com

3. 기술 지원 계약을 검토하십시오.

그만큼기술 지원 계약(TSA)는 SIOS가 SIOS 제품에 대해 제공하는 지원 내용을 설명합니다. TSA는 유지 관리, 업그레이드와 관련된 중요한 정보를 파악하는 데 유용합니다.제품 지원또한 제품 수정 사항도 포함되어 있습니다. TSA는 SIOS의 연중무휴 24시간 지원 서비스 및 문의처에 대한 유용한 정보도 제공합니다. TSA를 이해하면 SIOS 팀의 지원을 받을 수 있다는 확신을 얻을 수 있습니다. 또한 TSA를 이해하면 지원 범위와 제외 사항을 명확히 파악하여 배포 및 유지 관리 과정에서 예상치 못한 문제가 발생하는 것을 방지할 수 있습니다.

4. SIOS 관리자 교육을 이수하십시오.

전환이 급하게 필요한 경우, 기존 관리자가 없어 교육을 제공받지 못할 수도 있습니다. 하지만 걱정하지 마세요. SIOS에서 편리한 온라인 교육을 제공합니다. 이 교육은 LifeKeeper for Linux 제품에 대한 포괄적인 개요와 관리자에게 필요한 역할 및 작업에 대해 설명합니다. 담당자 정보가 런북에 기재되어 있다면 담당자에게 직접 문의하세요. 그렇지 않은 경우, SIOS 웹사이트를 방문하세요.sales@us.sios.com또는support@us.sios.com도움이 필요합니다.

5. 데모 또는 테스트 클러스터를 생성합니다.

관리자 교육을 이수했다면, 회사 데이터나 애플리케이션에 직접적인 위험을 초래하지 않고 기술과 이해도를 연습하고 향상시킬 수 있는 테스트 환경을 구축하세요. 데모를 만들거나테스트 클러스터이를 통해 여러분과 여러분의 미래 팀은 제품의 기본 사항을 이해하고 사용자 인터페이스에 익숙해질 수 있습니다.

또한, 팀이 런북을 인수한 경우, 런북을 기반으로 자체 클러스터를 구축하면 향후 런북을 검증하고 업데이트하는 데 도움이 됩니다. 가능하면 프로덕션 클러스터에서 보호되는 애플리케이션과 데이터를 최대한 유사하게 구성하십시오. 이상적으로는 팀에서 구축하는 테스트 클러스터가 프로덕션 시스템과 최대한 유사해야 합니다. 이를 통해 팀은 프로덕션 환경에서 명령을 실행하기 전에 안전한 환경에서 종속성, 동작 및 운영 방식을 이해할 수 있습니다. 다음과 같은 몇 가지 핵심 연습을 반드시 수행하십시오.

1. 수동 전환
2. 서버 장애 조치
3. 애플리케이션 복구
4. 유지보수 작업

6. 클러스터 상태 점검을 예약하세요

에이클러스터 상태 점검SIOS LifeKeeper for Linux 환경 전체를 검증합니다. 이는 고가용성(HA) 클러스터에 대한 다단계 점검이라고 생각하시면 됩니다. SIOS 전문가 팀이 시스템 로그, 시스템 설정, 실행 설명서, LifeKeeper 운영 및 기타 문서를 자세히 검토하고 검증하여 애플리케이션 복구 키트를 포함한 LifeKeeper 환경이 최적화된 방식으로 구성 및 운영되고 있는지 확인합니다. 상태 점검 보고서에는 운영 개선 및 위험 완화, 잠재적 문제 해결, 제품 이해도 향상을 위한 권장 사항이 포함되어 있습니다.

7. SIOS의 지원 및 전문 서비스를 활용하십시오.

A팀은 단 한 명의 개인이 중요한 임무를 수행하는 팀이 아니라, 하나의 팀이었습니다. 여러분이 좋아하는 밴드도 마찬가지로, 보컬, 드러머, 기타리스트 한 명 이상의 존재입니다. 그들은 위대한 목표를 달성하고, 훌륭한 음악을 만들고, 팬들을 실망시키지 않고, 매진된 공연의 기쁨을 누리고자 하는 뜻을 같이하는 전문가들의 모임입니다. 카를로스의 성공에는 핸들러, 그루머, 코치, 트레이너, 산책 도우미, 수의사, 그리고 수많은 전문가와 에이전트의 노력이 담겨 있습니다. 그들의 성공은 팀워크의 결과이며, 여러분의 성공 또한 마찬가지입니다. SIOS 지원팀을 적극 활용하세요.support@us.sios.com또는 지원 포털을 통해support.us.sios.com귀중한 통찰력과 정보를 얻기 위해.

SIOS 지원 포털에는 수백 개의 유용한 기술 자료(KBA)와 최신 소프트웨어에 대한 접근 권한이 제공되며, 엔지니어의 도움을 받아 성공적인 운영을 할 수 있습니다. SIOS 지원팀에 문의하여 지원 포털 로그인 정보를 확보하고 클러스터를 효율적으로 관리하세요. 지원팀은 다양한 SIOS 관련 서비스에 대한 접근 권한도 제공해 드립니다.전문 서비스더욱 심화된 교육, 추가적인 상태 점검 및 검증, 새로운 클러스터 설치 지원, 또는 최초 또는 향후 유지 관리 또는 가동 기간을 위한 대기 엔지니어링 서비스 등 다양한 혜택을 제공합니다.

8. SIOS와 지속적으로 소통하세요

새로운 클러스터를 인수할 때 성공의 비결은 SIOS와 지속적인 소통을 유지하는 것입니다. 담당 계정 관리자와 정기적으로 연락하여 진행 상황을 점검하십시오. 이러한 소통을 통해 새로운 옵션과 기회를 파악하고, 라이선스 갱신을 미리 준비하며, 추가 애플리케이션 및 서비스 보호를 확장하기 위해 새로운 클러스터를 추가하는 방법을 이해할 수 있습니다.

뉴스레터와 이메일 알림을 통해 SIOS 지원팀과 지속적으로 소통하세요. 이메일 알림은 소프트웨어에 영향을 줄 수 있는 새로운 기능, 릴리스 또는 중요 업데이트에 대한 정보를 제공합니다. 근본 원인 분석(RCA)에 대한 명확한 설명이 필요하거나 전문가의 도움이 필요한 문제가 발생하면 지원 이메일 사서함 또는 지원 포털을 통해 케이스를 개설하세요.

SIOS LifeKeeper for Linux 클러스터를 인수하는 것이 결코 부담스럽게 느껴질 필요는 없습니다.데모를 요청하세요SIOS가 핵심 애플리케이션 보호, 다운타임 위험 감소, 고가용성 관리 등에 어떻게 도움이 되는지 알아보세요.

작가:카시우스 루, SIOS 테크놀로지 사 고객 경험 담당 부사장

허가를 받아 재게재되었습니다.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

기존 인프라에서 고가용성을 유지하는 데 따르는 3가지 과제

기존 인프라에서 고가용성을 유지하는 데 따르는 3가지 과제

고가용성(HA)은 애플리케이션, 서비스 및 데이터에 대한 지속적인 접근이 필요한 조직에 매우 중요합니다. 고객 대면 플랫폼 지원이든 내부 비즈니스 운영이든, 시스템 다운타임은 재정적 손실, 생산성 저하 및 기업 이미지 손상으로 이어질 수 있습니다. 많은 기업들이 비용, 호환성 또는 비즈니스 요구 사항 때문에 기존 인프라를 계속 사용하고 있지만, 오래된 환경에서 고가용성을 유지하는 것은 시간이 지날수록 점점 더 어려워집니다. 기존 IT 시스템은 최신 플랫폼이 피하도록 설계된 기술적 한계와 운영상의 위험을 내포하는 경우가 많습니다.

기존 인프라에서 가장 흔한 문제 중 하나는 소프트웨어 패키지, 라이브러리 및 시스템 구성 요소 간의 호환성 문제가 점점 심각해진다는 것입니다. 오래된 기술은 종종 디커플링이 제대로 구현되기 훨씬 전에 설계된, 서로 밀접하게 연결된 종속성 위에 구축됩니다. 시간이 지남에 따라 소프트웨어가 크게 변경되거나 더 이상 유지 관리되지 않아 이러한 시스템을 업데이트하기가 어려워집니다.

다음은 오래된 인프라에서 발생할 수 있는 문제점의 몇 가지 예입니다.

• 패키지나 라이브러리 하나를 업데이트하면 이전 버전에 의존하는 다른 구성 요소가 의도치 않게 손상될 수 있습니다. 저도 이런 경험을 해봤는데, 하나의 종속성이 다른 종속성으로 이어지고 또 다른 종속성으로 이어지면서 수십 개의 패키지를 다시 컴파일하는 데 몇 시간이 걸리기도 했습니다!
• 서비스 간 상호 작용 방식에 대한 문서가 부족하면 업그레이드가 어려워질 수 있습니다.
• 마지막으로, 최신 모니터링, 보안 또는 자동화 도구는 구형 시스템과 원활하게 통합되지 않을 수 있습니다. 고가용성(HA) 환경에서는 사소한 호환성 문제조차도 심각한 장애를 초래할 수 있습니다.

고가용성 전략의 일환으로 인프라 현대화 계획을 수립하십시오.

유지높은 가용성오래된 인프라는 기술적, 운영적 측면 모두에서 어려움을 야기합니다. 패키지 호환성 문제, 제한적인 공급업체 지원, 그리고 내부 전문성 저하는 모두 시스템 안정성을 위협하고 다운타임 위험을 증가시킬 수 있습니다.

기존 시스템이 중요한 비즈니스 기능을 계속 수행할 수 있지만, 조직은 핵심 전문 지식이 손실되기 전에 인프라 현대화 계획을 수립하고, 문서화 방식을 개선하며, 지식 이전에 투자해야 합니다. 강력한 고가용성(HA) 전략은 미래를 위한 장기적인 신뢰성, 보안 및 운영 복원력을 보장하는 것입니다.

저자: 캐시 헨드릭스-싱케, SIOS IT 운영 부문 선임 시스템 엔지니어

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

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

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 엔터프라이즈 지원 가이드: 플랜 보장 내용

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