Linux 환경에서 SQL Server에 대한 고 가용성을 제공하는 방법

조직이 Linux에서 업무상 중요한 Microsoft SQL Server를 실행하는 경우 IT 팀은 의심 할 여지없이 고 가용성, 성능 및 보안을 지속적으로 유지 관리하는 것이 얼마나 어려운지 알고 있습니다. 특히 어려운 것은 강력한 복제 및 자동 장애 조치로 고 가용성을 보장하는 방법입니다. 오픈 소스 소프트웨어와 쉽게 구성 할 수있는 HA SANless 클러스터 솔루션을 사용하면 조직에 필요한 안전과 성능을 희생하지 않고도보다 간단한 유지 관리 방식을 제공 할 수 있습니다.

Linux에 대한 제한된 고 가용성 옵션

대부분의 Linux 배포판은 IT 부서에 고 가용성을위한 두 가지 열등한 선택을 제공합니다. SQL Server Enterprise Edition에 Always On 가용성 그룹을 구현하는 데 더 많은 비용을 지불하거나 복잡한 DIY HA Linux 구성이 제대로 작동하도록하는 데 어려움을 겪는 것입니다. 하기 어렵다.

Enterprise Edition 사용의 문제점은 상용 하드웨어에서 오픈 소스 운영 체제를 사용하기위한 비용 절감 전략을 약화 시킨다는 것입니다. 제한된 수의 소규모 SQL Server 응용 프로그램의 경우 추가 비용을 정당화 할 수 있습니다. 그러나 많은 데이터베이스 애플리케이션에 비해 너무 비싸고 Linux 용 범용 HA를 제공하는 데 아무 일도하지 않습니다.

Pacemaker 및 Corosync 또는 SUSE Linux Enterprise High Availability Extension과 같은 오픈 소스 소프트웨어를 사용하여 Linux 환경에서 실행되는 모든 애플리케이션에 HA를 제공 할 수 있습니다. 그러나 전체 소프트웨어 스택이 원하는대로 작동하려면 각 응용 프로그램에 대한 사용자 지정 스크립트를 만들고 테스트해야하며 이러한 스크립트는 사용중인 소프트웨어 나 하드웨어를 약간 변경 한 후에도 종종 다시 테스트하고 업데이트해야합니다. SQL Server Standard Edition과 Linux 모두에서 지원되지 않는 가용성 관련 기능은 이러한 노력을 더욱 어렵게 만들 수 있습니다.

Linux에서 SQL Server를위한 대체 고 가용성 솔루션 찾기

HA를 비용 효율적이고 쉽게 구현하기 위해 두 가지 다른 범용 접근 방식을 고려할 수 있습니다.

하나는 중복되고 탄력적 인 SAN (Storage Area Network) 내에서 데이터를 복제하여 데이터를 보호하는 스토리지 기반 시스템을 사용하는 것입니다. 이 접근 방식은 호스트 운영 체제와 관련이 없지만 전체 SAN 인프라를 단일 공급 업체로부터 확보해야하며 고 가용성을 제공하기 위해 별도의 장애 조치 프로비저닝에 의존해야합니다.

다른 접근 방식은 호스트 기반이며 Linux 서버 인스턴스에서 스토리지에 구애받지 않는 SANless 클러스터를 만드는 것입니다. HA 오버레이로서 이러한 클러스터는 사설, 공용 및 하이브리드 클라우드의 LAN과 WAN 모두에서 작동 할 수 있습니다. 또한 오버레이는 애플리케이션에 구애받지 않으므로 조직이 모든 애플리케이션에서 단일 범용 HA 솔루션을 가질 수 있습니다. 이 접근 방식은 호스트 리소스를 소비하지만 비교적 저렴하고 Linux 환경에서 쉽게 확장 할 수 있습니다.

대부분의 HA SANless 클러스터 옵션은 실시간 블록 수준 데이터 복제, 지속적인 애플리케이션 모니터링, 구성 가능한 장애 조치 / 장애 복구 정책의 조합을 제공하여 Standard Edition에서 사용할 수있는 Always On 장애 조치 클러스터 인스턴스를 사용하는 애플리케이션을 포함하여 모든 비즈니스 크리티컬 애플리케이션을 보호합니다. SQL Server의.

SIOS Technology Corp.는 컴퓨팅 인프라를 지원하고 최적화하는 복잡성과 일상적인 문제에서 IT를 해방하도록 설계된 고급 기능을 갖춘 Linux 용보다 강력한 HA SANless 클러스터 솔루션을 제공합니다. LifeKeeper가 포함 된 SIOS Protection Suite 솔루션은 다음을 제공합니다.

• 전체 Linux 애플리케이션 스택에 대한 지속적인 모니터링
• 복잡한 애플리케이션 및 데이터베이스의 빠르고 안전한 복구 또는 페일 오버를위한 애플리케이션 복구 키트 (ARK)로 완벽한 애플리케이션 인식 보호
• Linux 클러스터링을위한 마법사 기반 설정
• 기존 공유 스토리지 클러스터 또는 소프트웨어를 사용하여 SANless 클러스터 구성에서 로컬 스토리지를 동기화하는 것과 같은 구성 유연성

예를 들어 SANless 클러스터는 두 개의 동시 오류를 처리 할 수 있습니다. 기본 작동은 LAN 및 WAN뿐만 아니라 사설, 공용 및 하이브리드 클라우드에서 동일합니다.

일반적인 2 노드 클러스터에서 서버 # 1은 처음에 데이터를 서버 #에 복제하는 기본 서버입니다. 문제가 발생하여 이제 기본 서버가되는 서버 # 2에 대한 장애 조치가 자동으로 트리거됩니다.

이 상황에서 IT 부서는 서버 # 1의 장애를 유발 한 모든 문제를 진단하고 수리하기 시작할 것입니다. 일단 수정되면 주 서버 또는 서버 # 2가 해당 용량에서 계속해서 데이터를 서버 # 1에 복제 할 수 있으므로 인계 될 수 있습니다.

대부분의 HA SANless 클러스터링 구성에서 장애 조치는 자동이며 브라우저 기반 콘솔에서 장애 조치와 장애 복구를 모두 제어 할 수 있습니다.

SIOS LifeKeeper 및 Protection Suite 솔루션에 대한 자세한 내용은 클러스터 서버 환경 용 SIOS SAN 및 SANless 고 가용성 클러스터를 참조하세요.

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, 고객 경험