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

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

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

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

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

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

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

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

‘전환’은 계층 구조를 기본 노드에서 보조 노드로 수동으로 이동하는 작업입니다. 이 작업은 보조 노드에서 ‘서비스 중’을 수행하거나 명령줄을 통해 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가 시작되거나 실패한 통신 경로가 복원되면 감시 노드(감시 장치)가 참조됩니다. 증인 확인은 쿼럼이 있는 노드에 대해서만 수행할 수 있습니다.

2. 자원 장애 원인

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 인프라를 보호하고 최적화하는 제품입니다.오늘 저희에게 연락하십시오자세한 내용은.

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

더 나은 지원을 위한 세 가지 팁

더 나은 지원을 위한 세 가지 팁

Betsy는 1999년형 Amazon Green Ford F-150으로 제가 구입한 첫 번째 차량이었습니다. 내 트럭이 Betsy라는 이름을 어떻게 얻었는지, 왜 붙었는지 잘 모르겠지만 그랬습니다. 17년 넘게 Betsy는 해변 순항부터 경주장 경주, 수많은 조경 용품 운반, 성장하는 가족을 남동쪽으로 데려가는 일까지 모든 일을 했습니다. 수 마일, 수년 동안 트럭 관리 방법을 배운 후, 그녀는 마모를 보이기 시작했습니다. 특정 오후 운전에서 온도 게이지가 H(높음)까지 올라가는 것을 발견했습니다. 몇 번의 대화 끝에 나는 일주일 간의 자해 시련을 시작하기 위해 Betsy를 지역 대리점의 서비스 부서로 데려갔습니다.

첫 번째 방문에서 나는 급히 높은 수준의 세부 사항을 제공했습니다. “몇 분이 지나면 트럭이 뜨거워지죠.” 내가 말했습니다. 6시간 후 100달러를 내고 트럭을 찾았습니다. 기술자가 문제를 재현할 수 없었습니다. 그래서 진단비와 재발하면 다시 오라는 요청과 함께 집으로 보내졌습니다. 두 번째 방문에서는 출퇴근 시간을 45분 이상 운전한 지 18분, 즉 14마일 후에 문제가 발생했다고 서둘러 덧붙였습니다. 6시간이 지나고 약 375달러가 지나서 나는 트럭을 찾았습니다. 기술자는 새로운 세부 사항으로 문제를 재현할 수 있었고 온도 조절 장치와 호스를 교체했습니다. 세 번째 방문에서는 기술자의 전화가 일찍 왔습니다. 루, 새 라디에이터가 필요할 것 같아요.”

그것은 이야기의 짧은 버전입니다. 더 긴 버전에는 첫 번째 방문과 두 번째 방문 사이에 이미 온도 조절 장치를 교체했다는 사실을 서비스 기술자에게 설명하지 못한 것이 포함됩니다. 또한 내가 라디에이터 유체를 플러시하고 채우는 작업을 수행했으며 그 과정에서 호스 클램프를 느슨하게 남겨두었을 가능성이 높다는 사실도 생략되었습니다. 무엇보다도 트럭에 이런 문제가 발생하기 전에 정비사인 이웃이 나에게 라디에이터를 교체하고 기타 예방적 유지 관리를 수행하라고 말했다는 사실이 빠져 있습니다. 그렇다면 이것이 더 나은 고객 경험과 어떤 관련이 있습니까?

다음은 귀하의 다음 자동차 서비스뿐만 아니라 귀하의 고객 경험을 향상시킬 자해 시련에서 얻은 세 가지 교훈입니다.

먼저 모든 세부 사항을 확인하고 제공하십시오.

처음 방문했을 때 서비스 기술자에게 최소한의 세부 정보를 급히 제공했습니다. 그 결과, 적절한 해상도를 얻을 수 없었습니다. 전 세계의 많은 이벤트는 가장 부적절한 시기에 발생하며 많은 압박감과 시간 제약을 수반하지만 고객 경험 팀에 가능한 한 많은 세부 정보를 제공하는 것이 여전히 모범 사례입니다. 언제 문제를 발견했습니까? 또는 언제 문제가 발생했습니까? 무엇을 발견했거나 문제의 증상이 무엇이었나요? 당시에는 또 어떤 일이 벌어지고 있었나요?

오류 메시지 및 오류 코드, 소프트웨어 시스템 로그, 클라이언트 로그 및 오류 조건이나 증상을 캡처하는 사진을 포함하여 제공할 수 있는 기타 지원 세부 정보를 고려하세요. 우리는 소프트웨어에 있는 것들이 서로 관련이 없다고 생각하고 싶어하지만 실제로는 매우 관련이 많습니다.

둘째, 당신이 한 일(좋은 일이든 나쁜 일이든)을 설명하십시오.

두 번째 방문을 하러 왔을 때 나 자신과 기술자들에게 또 다른 큰 해를 끼쳤습니다. 이미 시도한 모든 것(좋은 점과 나쁜 점)을 설명하고, 문제를 해결하기 위해 실패한 시도에 대해 공유하기보다는 해결을 미루었습니다. 내가 이미 온도 조절 장치를 교체하고 라디에이터 세척 및 재충전을 수행했다는 사실을 공유했다면 아마도 기술자는 문제를 다른 곳에서 찾았을 것입니다. 문제를 해결하기 위해 수행한 작업과 문제를 악화시키기 위해 수행한 작업을 공유하면 고객 경험 팀이 대응을 개선하고, 다른 문제 영역을 조사하고, 허위 문제(관련 없는 문제 또는 사물)를 제거하는 데 도움이 됩니다. 실제 문제로 가장하여) 전반적으로 더욱 뛰어난 경험을 제공합니다.

마지막으로 이전 권장 사항을 실행합니다.

문제가 표면화되기 전에 이웃은 자신의 경험과 내 트럭의 연식을 바탕으로 추천 사항을 제시했습니다. 그는 나에게 라디에이터를 교체하고 예방적 유지 관리를 수행하며 트럭의 전반적인 상태를 정기적으로 점검하라고 말했습니다. 아마도 고객 경험 팀은 기업 가용성 요구 사항에 따른 운영과 관련된 제품 및 수년간의 경험과 관련된 지식 기반에 권장 사항을 갖고 있을 것입니다. 예방적 유지 관리, 사전 조정, 가용성 환경이 모범 사례를 준수하는지 확인하는 데 이를 사용하세요. 하지만 가장 중요한 것은 그들이 추천을 하면 실행하는 것입니다. 결국에는 많은 시간, 돈, 번거로움을 절약할 수 있습니다.

세 번째 방문 이틀 후, 새 라디에이터에 대한 예약 주문이 도착했고 나는 라디에이터를 교체했습니다. 나는 Betsy를 몇 년 더 계속 운전하다가 마침내 가족용 SUV로 교체했습니다.

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

Udemy에서 Linux 관리자 교육용 SIOS LifeKeeper를 이용할 수 있습니다.

Udemy에서 Linux 관리자 교육용 SIOS LifeKeeper를 이용할 수 있습니다.

이전에는 주로 사전 예약된 격월 이벤트를 통해 액세스할 수 있었던 SIOS 관리자 교육이 이제 Udemy를 ​​통해 주문형으로 제공됩니다.

SIOS 기술Linux 관리자 교육용 SIOS LifeKeeper를 사용할 수 있다고 발표했습니다.유데미, 온라인 기술 시장 및 학습 플랫폼입니다. 이번 개발은 전 세계 기업에 포괄적인 고가용성 및 재해 복구 기능을 제공함으로써 중요한 애플리케이션의 가용성을 촉진하려는 SIOS의 헌신을 강조합니다(HA/DR) 기술 교육.

Udemy의 플랫폼은 비교할 수 없는 편의성과 유연성을 제공하여 학습자가 언제 어디서나 SIOS 관리 교육에 액세스할 수 있도록 합니다. Linux 관리용 SIOS LifeKeeper 교육은 하드웨어 또는 소프트웨어 오류가 발생하는 경우에도 중요한 Linux 애플리케이션, ERP 및 데이터베이스를 항상 사용할 수 있도록 하는 데 필요한 핵심 개념과 방법론을 다룹니다.

SIOS Technology Corp의 글로벌 영업 및 마케팅 부사장인 Margaret Hoagland는 “Udemy와의 이번 파트너십은 SIOS HA/DR 전문 지식을 모든 사람이 이용할 수 있도록 하는 우리의 사명에서 중요한 이정표입니다.”라고 말했습니다. “Udemy의 플랫폼을 활용함으로써 우리는 더 넓은 범위에 도달할 수 있습니다. IT 전문가 청중에게 조직의 고가용성과 재해 복구를 보장하는 데 필요한 지식과 기술을 제공합니다.”

예비 학습자는 먼저 Udemy(www.udemy.com)에서 무료 계정을 만들고 비즈니스 이메일로 등록하여 Linux 관리용 SIOS LifeKeeper 교육 과정에 액세스할 수 있습니다. 등록이 완료되면 양식을 제출합니다.SIOS 교육 사이트, Udemy에 등록할 때 사용한 것과 동일한 비즈니스 이메일을 사용하여 강좌 초대를 받습니다.

허가를 받아 복제됨시오스

SIOS 기술, Nutanix Elevate 파트너 프로그램에 합류

SIOS 기술, Nutanix Elevate 파트너 프로그램에 합류

SIOS 기술 공사. 에 회원임을 발표했다.Nutanix Elevate 파트너 프로그램, Nutanix AHV 환경 내의 중요한 애플리케이션을 위한 사용하기 쉬운 HA 클러스터링 솔루션을 제공하는 데 획기적인 이정표를 세웠습니다.

SIOS에 수여된 Nutanix Ready 검증 지정 완료는 SIOS를 입증합니다.생명의 수호자그리고데이터키퍼Nutanix 인프라와의 상호 운용성. 이번 검증의 일환으로 두 파트너는 공동 고객이 지속적인 혁신을 통해 이익을 얻을 수 있도록 협력하고 있습니다.

SIOS의 실적에는 전 세계적으로 설치된 80,000개 이상의 라이선스로 HA 및 DR을 활성화하여 다양한 산업 분야의 기업을 위한 애플리케이션을 보호하는 고객을 위한 성공적인 구현이 포함됩니다.

LifeKeeper 및 DataKeeper 제품은 검증 테스트를 완료하여 고객에게 솔루션의 호환성에 대한 확신을 더할 수 있습니다. Linux용 LifeKeeper를 통해 Nutanix는 심층적인 HA 전문 지식을 바탕으로 비즈니스 크리티컬 애플리케이션을 위한 간단하고 안정적인 HA를 고객에게 제공할 수 있습니다. SIOS 제품을 사용하면 SAP, HANA, SQL Server 및 SUSE Linux, Red Hat Linux, Oracle Linux, Rocky Linux 및 Windows Server에서 실행되는 기타 환경과 같이 본질적으로 복잡한 환경을 갖춘 Nutanix 고객은 구현, 유지 관리를 통해 시간을 절약하고 비용이 많이 드는 가동 중지 시간을 제거할 수 있습니다. , 안정적이고 신뢰할 수 있는 HA 환경을 관리합니다.

SIOS 글로벌 마케팅 부사장인 Margaret Hoagland는 다음과 같이 말했습니다. “Nutanix Elevate 파트너 프로그램에 참여하는 것은 강력한 HA 솔루션을 고객에게 제공하고, 범위를 확장하며, Nutanix 사용자에게 중단 없는 안정성과 단순성을 제공하려는 우리의 약속을 입증하는 것입니다. 중요한 애플리케이션을 위한 운영이 가능합니다.”

“Nutanix Ready Validated” 지정을 받은 SIOS 제품은 다음과 같습니다.

• Linux 9.8.0용 LifeKeeper
• Windows 8.10.0용 LifeKeeper
• Windows 8.10.0용 DataKeeper

LifeKeeper for Linux는 가장 광범위한 Linux OS 배포판, 버전 및 플랫폼에 HA를 제공합니다. 온프레미스, 가상, 클라우드. SIOS의 HA/DR 제품 포트폴리오에는 대역폭 효율적인 호스트 기반 블록 수준 복제, 애플리케이션 복구 키트(ARK)가 포함되어 있어 SAP, HANA 및 기타 널리 사용되는 데이터베이스 및 애플리케이션에 대한 애플리케이션 인식을 활성화할 뿐만 아니라 일반 사용자 정의 가능한 ARK도 가능합니다. LifeKeeper for Linux는 애플리케이션, 데이터베이스 및 스토리지에 대한 자동화된 모니터링, 문제 감지 및 지능형 복구를 제공하여 중요한 시스템과 애플리케이션의 가용성을 높게 유지합니다.

SIOS-Nutanix 솔루션에 대해 자세히 알아보기