SIOS 클러스터링 소프트웨어에 대한 라이센스를 활성화하는 방법

SIOS AppKeeper Monitoring으로 Apache 웹 서버 다운 타임 제거 *

오늘날 Apache 웹 서버는 인터넷에서 가장 인기있는 웹 서버입니다.  기업은 Amazon AWS, Microsoft Azure 및 Google Cloud Platform과 같은 클라우드 플랫폼을 사용하여 Apache에 구축 된 미션 크리티컬 한 고객 용 애플리케이션을 배포하고 있습니다.  따라서 이러한 애플리케이션을 모니터링하고 다운 타임을 줄이는 데 많은 시간과 비용을 투자하고 있음을 확신 할 수 있습니다. 그러나 Apache 웹 서버가 다운되었을 때 자동화 된 모니터링 및 애플리케이션 재시작을 통해 수동 개입의 필요성을 제거 할 수 있다고 말하면 어떨까요?

이를 수행하는 방법에 대해 알아보기 전에 잠시 뒤로 물러나 기업이 Apache 웹 서버와 중요한 애플리케이션을 모니터링하고 관리 할 때 선택할 수있는 사항을 살펴 보겠습니다.

불필요한 다운 타임으로부터 Apache 웹 서버를 모니터링하고 보호하는 방법

Apache 웹 서버를 사용하여 애플리케이션을 배포하는 사람은 누구나 웹 서버 자체의 상태를 모니터링하거나 해당 작업을 타사에 아웃소싱하는 것을 고려하고 있습니다.

Amazon Web Services에서 실행되는 클라우드 애플리케이션을 모니터링 할 때 인기있는 선택은 Amazon CloudWatch를 사용하는 것입니다.  일부 회사는 스크립트를 개발하거나 AWS Lambda를 사용하여 일정 수준의 자동화를 생성하여 CloudWatch의 기능을 확장하고 있습니다.  그러나 사용자 지정 지표를 사용하여 Amazon CloudWatch를 올바르게 구성하고 AWS Lambda를 설정하려면 많은 회사를 능가하는 특정 기술 전문 지식이 필요합니다.  그리고 응용 프로그램이 발전함에 따라 스크립트를 유지 관리하는 데 필요한 비용과 노력이 있습니다.

또 다른 선택은 New Relics, Dynatrace, DataDog 또는 LogicMonitor와 같은 공급 업체의 포괄적 인 애플리케이션 성능 모니터링 ( "APM") 솔루션에 투자하는 것입니다. AWS 환경뿐만 아니라 더 많은 것을 모니터링하려는 경우 매우 적합 할 수 있습니다. APM 솔루션은 매우 구성 가능하며 발생한 일에 대한 정보 측면에서 많은 데이터를 제공합니다.

하지만 다운 타임을 줄였습니까? 아마 아닐 것입니다.  여러분이 한 일은 Apache 웹 서버가 다운되면 즉시 경고하고 다시 실행하려고 할 때 데이터 (또는 "경보 폭풍")로 과부하를 일으키는 시스템에 투자 한 것입니다.

일부 회사는 애플리케이션 모니터링 및 관리 책임을 신뢰할 수있는 제 3 자 (종종 "관리 서비스 공급자"또는 MSP)에게 아웃소싱하기로 결정했습니다. 기본 월별 요금에 대한 대가로 MSP는 애플리케이션을 모니터링하고 종종 서비스 수준 계약에 구속되는 핵심 서비스 세트를 제공합니다. 경보가 수신되면 조사합니다. 경우에 따라 이러한 조사에는 (비용이 많이 드는) 에스컬레이션이 필요할 수 있습니다. 애플리케이션이 다운되면 MSP가 제어권을 가지고 서비스를 다시 시작하거나 가능한 경우 인스턴스를 재부팅합니다.  그러나 이러한 수정 조치는 종종 추가 비용이 듭니다.

더 나은 방법이 있어야합니다.

SIOS AppKeeper로 자동화 된 모니터링 및 재시작이 Apache 웹 서버 다운 타임을 제거하는 방법

고객 경험을 기준으로 볼 때 EC2 인스턴스가 3 개 뿐인 일반 회사는 적어도 한 달에 한 번 다운 타임을 경험합니다.  “사이트가 다운되었습니다! 모든 것을 버리십시오. 무엇을해야하는지 알아보십시오!” 여러분이해야 할 일은 이러한 불필요한 소방 훈련의 필요성을 줄이는 것입니다.

SIOS AppKeeper는 Apache httpd 서비스와 같이 Amazon EC2에서 실행되는 모든 서비스 및 애플리케이션을 쉽게 설치 및 구성하고 모니터링하는 SaaS 서비스입니다.  이상이 감지되면 AppKeeper는 자동으로 서비스를 다시 시작하고 작동하지 않으면 전체 인스턴스를 재부팅합니다. 더 이상 로그를 읽고 실패 원인을 찾아 내거나 서비스를 다시 시작하기 위해 개발자에게 에스컬레이션하지 않아도됩니다. 또는 비싼 아웃소싱 수수료.  AppKeeper는 "설정 후 잊어 버리기"기능을 제공하므로 다운 타임을 제거 할 수 있습니다.

오늘날 수백 개의 기업이 AppKeeper를 사용하여 클라우드 환경을 계속 실행하고 있습니다. AppKeeper가 Apache 웹 서버를 보호하는 방법에 대한 데모를 보려면 아래 비디오를 확인하십시오.  마음에 드시면 AppKeeper의 14 일 무료 평가판에 가입하세요.

* 고객 데이터에 따르면 AppKeeper는 애플리케이션 서비스 오류의 85 %를 해결합니다. 따라서 10 명 중 거의 9 번에 걸쳐 AppKeeper는 고객에게 다운 타임이 감지되고 서비스가 다시 시작되었거나 인스턴스가 자동으로 재부팅되었음을 알리는 이메일을 보냅니다.  수동으로 모든 것을 다시 시작하기 전에 당황하고 로그 파일을 검색하는 것보다 낫지 않습니까?

관련 게시물 참조 : AWS EC2 애플리케이션 모니터링이 왜 그렇게 어려운가요?

Linux 구성에 대한 SIOS Protection Suite 복원을위한 팁

"임의의 동료"잘하셨습니다! 그리고 좋은 직업이라고해서 정말 좋은 직업을 의미하지는 않았습니다.  그리고“Random Coworker”란 체크하지 말아야 할 상자를 체크하거나 체크를 해제 한 사람, 메시지와 경고를 생략 한 남녀, 안전 대책을 Linux 용 SIOS Protection Suite 구성을 망쳤습니다.

우리 모두 거기에있었습니다.  사고였습니다.  그러나 그것은 일어났습니다.  갑자기 당신은 상사가 알아 내기 전에 구성, 데이터 및 "무엇이든"을 복구하기 위해 무엇을해야하는지 파악하려고 애 쓰고 있습니다.

SIOS Technology Corp.의 고객 경험 담당 부사장으로서 우리 팀은 파트너 및 고객과 적극적으로 협력하여 시스템을 다운 타임으로부터 보호하기 위해 엔터프라이즈 가용성을 설계하고 구현하고 있습니다.  사고가 발생하고 최근 고객 경험을 통해 여러 번의 확인 및 경고를 받았음에도 불구하고 Linux 용 SIOS Protection Suite 제품도 우발적 인 구성 변경에 영향을받지는 않지만“Random Coworker 's에서 빠른 복구를위한 간단한 팁이 있습니다. "우연한 실수.

실수로 구성을 변경 한 후 Linux 용 SIOS Protection Suite를 복구하는 방법 

Linux 용 SIOS Protection Suite (SPS-L)의 기본은 / opt / LifeKeeper / bin / lkbackup 아래에있는 lkbackup이라는 도구입니다.  이름에서 알 수 있듯이이 도구는 SPS-L 구성 세부 정보의 백업을 생성합니다.  참고 :이 도구는 모든 애플리케이션 데이터를 백업하지는 않지만 리소스 정의, / etc / default / LifeKeeper 파일에 구성된 튜너 블, 고객이 만든 일반 등 SPS-L 구성에 대한 모든 데이터의 백업을 만듭니다. 응용 프로그램 스크립트, 클러스터 상태와 관련된 플래그, 통신 경로 / 클러스터 정의 등.

[root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -c -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh

예 : : lkbackup create 구문

그러면 / root 폴더 아래에 mylkbackup-5.15.2020-v9.4.1이라는 백업 파일이 생성됩니다.  –cluster는 lkbackup에 각 클러스터 노드에 동일한 파일을 만들도록 지시합니다.  –ssh는 ssh 프로토콜을 사용하여 각 클러스터 노드에 연결합니다.  추가 lkbackup 세부 정보는 다음과 같습니다.

고객 경험 서비스 팀은 업그레이드, 리소스 제거 또는 추가 또는 구성 변경과 같은 SPS-L 구성 변경을 수행하기 전에 백업을 수행 할 것을 권장합니다.

따라서 SPS-L 구성을 복원해야하는 경우 변경은 lkbackup을 다시 실행하는 것만 큼 간단합니다.

[root@baymax ~ ] # / opt / LifeKeeper / bin / lkbackup -x -f /root/mylkbackup-5.15.2020-v9.4.1 –cluster –ssh

예 : lkbackup 복원 구문

자동 백업 기능은 lkbackup 파일을 자동으로 캡처합니다. 

그러나 "Random Coworker"가 SPS-L 설정 및 구성 시간을 낭비하기 전에 lkbackup을 실행하여이 파일을 만드는 것을 잊은 경우 어떻게해야합니까? SPS-L을 설정 한“Guy”또는“Gal”이 휴가, 육아 또는 출산 휴가 중이면 어떻게합니까? 만약 당신이“무작위 동료”이고 Basis 팀의 Steve가 일이 어떻게 진행되고 있는지 확인하기 위해 복도를 향하고 있다면? 대부분의 설치에서 SIOS는 설치 중에 자동 백업 기능을 활성화합니다.  이 자동 백업 기능은 / opt / LifeKeeper / config / auto-backup에서 현지 시간으로 오전 3시에 lkbackup 파일을 자동으로 캡처합니다. #. tgz

[root@baymax ~]# ls -ltr /opt/LifeKeeper/config/auto-backup.*

• -rw-r–r–. 1 루트 루트 31312 5 월 6 일 03:00 /opt/LifeKeeper/config/auto-backup.3.tgz
• -rw-r–r–. 1 루트 루트 31310 5 월 7 일 03:00 /opt/LifeKeeper/config/auto-backup.4.tgz
  -rw-r–r–. 1 루트 루트 31284 5 월 8 일 03:00 /opt/LifeKeeper/config/auto-backup.5.tgz
  -rw-r–r–. 1 루트 루트 31290 5 월 9 일 03:00 /opt/LifeKeeper/config/auto-backup.6.tgz
  -rw-r–r–. 1 루트 루트 31291 5 월 10 일 03:00 /opt/LifeKeeper/config/auto-backup.7.tgz
  -rw-r–r–. 1 루트 루트 31295 5 월 11 일 03:00 /opt/LifeKeeper/config/auto-backup.8.tgz
  -rw-r–r–. 1 루트 루트 31280 5 월 12 일 03:00 /opt/LifeKeeper/config/auto-backup.9.tgz
  -rw-r–r–. 1 루트 루트 31333 5 월 13 일 03:00 /opt/LifeKeeper/config/auto-backup.0.tgz
  -rw-r–r–. 1 루트 루트 31325 5 월 14 일 03:00 /opt/LifeKeeper/config/auto-backup.1.tgz
  -rw-r–r–. 1 루트 루트 31359 5 월 15 일 03:00 /opt/LifeKeeper/config/auto-backup.2.tgz

예. 구성 / 자동 백업 목록의 출력

시스템이 올바르게 설치 및 구성되어 있으면 자동 백업이 매일 밤 실행되어 "무작위 동료"가 발생했을 때이를 처리 할 수 있습니다. 실수하기 전에 SPS-L auto-backup. #. tgz를 찾아 SPS-L lkbackup 도구를 사용하여 Linux 구성 용 SIOS Protection Suite를 검색하고 이전에 구성된 상태로 복원합니다.

[root@baymax ~ ] # lkstop; / opt / LifeKeeper / bin / lkbackup -c -f /opt/LifeKeeper/config/auto-backup.0.tgz

예 : 자동 백업을위한 lkbackup 복원 구문

필요에 따라 클러스터의 다른 노드에서이 작업을 반복합니다.

노트.  시스템이 자동 백업 파일을 생성하고 자신의 "Random Coworker"로부터 사용자를 보호하도록 구성되어 있지 않은 경우 SIOS는 SIOS 전문 서비스 엔지니어가 수행하는 설치 및 구성 서비스와 구성 상태 확인을 제공합니다.

— Cassius Rhue, VP, 고객 경험