이 블로그에서 다룰 내용은 일반 로드 밸런서 애플리케이션 복구 키트(ARK) Linux용 SIOS Lifekeeper 및 특히 Microsoft Azure에서 구성하는 방법에 대해 설명합니다. 나는 2노드 NFS 클러스터를 사용할 것이고 그들이 제공하는 NFS 내보내기는 궁극적으로 로드 밸런서를 통해 액세스될 것입니다.

SIOS는 Azure에서 실행되는 LifeKeeper 클러스터에서 클라이언트 리디렉션을 용이하게 하기 위해 이 ARK를 만들었습니다.

Azure는 무상 ARP를 지원하지 않으므로 클라이언트는 기존 클러스터 가상 IP 주소에 직접 연결할 수 없습니다. 대신 클라이언트는 로드 밸런서에 연결해야 하며 로드 밸런서는 트래픽을 활성 클러스터 노드로 리디렉션합니다. . Azure는 계층 4(TCP, UDP)에서 작동하는 로드 밸런서 솔루션을 구현하며, 로드 밸런서는 활성 노드를 결정할 수 있는 상태 프로브인 개인 또는 공용 프런트엔드 IP를 갖도록 구성할 수 있습니다. 백엔드 IP 주소(클러스터의 각 노드에 대해) 및 수신/발신 네트워크 트래픽 규칙.

일반적으로 상태 프로브는 애플리케이션의 활성 포트를 모니터링하고 해당 애플리케이션이 활성 상태인 노드를 결정합니다. SIOS 일반 로드 밸런서 ARK는 활성 노드가 사용자 정의 포트에서 수신 대기하도록 구성됩니다. 그런 다음 이 포트는 Azure 부하 분산 장치에서 상태 프로브 포트로 구성됩니다. 이렇게 하면 활성 클러스터 노드가 TCP 상태 확인 프로브에 응답하여 자동 클라이언트 리디렉션을 활성화할 수 있습니다.

Azure의 설치 및 구성은 간단하고 아래에 자세히 설명되어 있습니다.

Azure Portal 내에서 부하 분산을 선택합니다. 로드 밸런서를 만들고 이름과 함께 배포할 리소스 그룹을 선택합니다. 예를 들어 IMA와 함께 로드 밸런서를 사용하는 클러스터 유형과 일치하는 이름을 사용하고 싶습니다. -NFS-LB는 두 IMA-NFS 노드 앞에 위치합니다.

이것이 공개 또는 비공개 LB인지 여부를 결정할 수 있습니다. 이 경우 이 리소스 그룹 내에서만 사용할 수 있도록 NFS 서버를 전면에 내보이도록 프라이빗 로드 밸런서를 구성하고 있습니다.

이름, 리소스 그룹 등을 결정하면 로드 밸런서의 이름, 가상 네트워크, 서브넷 및 IP를 할당하라는 메시지가 표시됩니다. IP 주소는 LifeKeeper에서 가상 IP 주소로 생성할 IP 주소와 동일해야 합니다.

로드 밸런서에 대한 기본 정보가 입력되면 로드 밸런서를 제공하기 위해 백엔드에서 구성할 머신을 정의해야 합니다. 제 경우에는 이 백엔드 풀이 내가 사용하는 두 개의 노드로 구성됩니다. 내 NFS 서버.

로드 밸런싱 규칙이 필요하며 이는 로드 밸런서가 활성 노드로 라우팅할 트래픽을 결정하는 방법입니다. – 여기에 구성된 포트 번호는 로드 밸런서를 지원하도록 일반 애플리케이션을 구성할 때 SPS-L에서 사용됩니다. 이 예에서는 모든 트래픽을 활성 노드로 라우팅하는 "HA 포트"를 사용하고 있습니다. 라우팅할 트래픽을 제한하려면 특정 애플리케이션 포트를 지정할 수 있습니다.

프런트엔드 IP는 로드 밸런서 IP여야 하고 백엔드 풀은 로드 밸런서에서 사용하는 리소스로 구성한 노드여야 합니다. "HA 포트" 버튼이 선택되어 있고 "유동 IP"가 활성화되어 있는지 확인합니다. "TCP 재설정"은 비활성화된 상태로 둘 수 있습니다.

상태 프로브를 생성할 때 SIOS Protection Suite 내에서 일반 애플리케이션을 생성할 때 사용될 포트이므로 여기에서 구성한 포트를 기록해 두십시오. "간격" 및 "비정상 임계값"에 대한 표준 값을 사용할 수 있습니다. 애플리케이션별 요구 사항이 있는 경우 나중에 변경할 수 있습니다.

이제 로드 밸런싱 규칙이 상태 프로브로 완료되어야 합니다. "추가"를 선택하십시오 "추가"를 선택하면 Azure에서 로드 밸런서 배포를 시작합니다. 이 작업은 몇 분 정도 걸릴 수 있으며 완료되면 구성이 SIOS Protection Suite로 이동합니다.

참고: 백엔드 머신이 로드 밸런서 뒤에 구성되면 인터넷 게이트웨이에 액세스할 수 없으므로 시스템 업데이트와 같은 작업이 작동하지 않습니다. 백엔드 리소스 그룹에서 컴퓨터를 제거하여 인터넷 액세스를 다시 허용할 수 있습니다.

SIOS 보호 제품군으로 구성

이 블로그의 경우 SPS-L을 사용하여 보호하도록 3개의 NFS 내보내기를 구성했으며, 3개의 내보내기는 Azure 부하 분산 장치의 프런트 엔드 IP와 동일한 IP를 사용하도록 구성되었습니다. Datakeeper를 사용하여 내보내기에 저장된 데이터를 복제하고 있습니다.

첫 번째 단계는 스크립트를 얻는 것입니다. 가장 간단한 방법은 wget을 사용하는 것이지만 winscp 또는 유사한 도구를 사용하여 전체 패키지를 다운로드하고 rpm을 노드에 직접 업로드할 수도 있습니다. Lifekeeper 클러스터의 모든 노드에 핫픽스를 설치해야 합니다.

전체 복구 키트는 여기에서 얻을 수 있습니다. http://ftp.us.sios.com/pickup/LifeKeeper_Linux_Core_en_9.5.1/patches/Gen-LB-PL-7172-9.5.1 wget으로 부품을 찾을 수 있습니다. wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm.md5sum wget http://ftp.us.sios.com/pickup/Gen-LB-PL-7172-9.5.1/Gen-LB-readme.txt 다운로드가 완료되면 FTP 사이트에 기록된 값과 MD5 합계를 확인합니다.

다음과 같이 RPM을 설치하십시오. rpm -ivh steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154.x86_64.rpm 다음을 실행하여 설치가 성공했는지 확인하십시오. rpm -qa | grep steeleye-lkHOTFIX-Gen-LB-PL-7172 어떤 이유로 RPM을 제거해야 하는 경우 다음을 실행하여 수행할 수 있습니다. rpm -e steeleye-lkHOTFIX-Gen-LB-PL-7172-9.5.1-7154 .x86_64 다음은 이미 구성한 세 가지 NFS 내보내기를 보여주는 GUI입니다. SIOS Protection Suite 내에서 해야 할 일은 SIOS에서 제공하는 Hotfix 스크립트를 사용하여 Load Balancer를 정의하는 것입니다.

먼저 새 리소스 계층을 만들고 드롭다운에서 일반 응용 프로그램을 선택합니다. /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/에 있는 restore.pl 스크립트를 정의합니다. /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/에 있는 remove.pl 스크립트를 정의하십시오. /opt/Lifekeeper/SIOS_Hotfixes/Gen-LB-PL-7172/에 있는 quickCheck 스크립트를 정의하십시오. 로컬 복구 스크립트가 없으므로 이 입력을 지워야 합니다. 애플리케이션 정보를 묻는 메시지가 표시되면 상태 프로브 구성에서 구성한 것과 동일한 포트 번호(예: 54321)를 입력하려고 합니다. 서비스가 생성되면 서비스를 제공하도록 선택할 것입니다.

리소스 태그는 SPS-L GUI에 표시되는 이름입니다. 저는 쉽게 식별할 수 있는 이름을 사용하고 싶습니다.

모든 것이 올바르게 구성된 경우 "END 성공적인 복원"이 표시되면 리소스를 두 노드 중 하나에서 호스팅할 수 있도록 이를 다른 노드로 확장할 수 있습니다.

두 노드로 확장한 후 완료된 로드 밸런서 구성을 보여줍니다.

이 클러스터의 마지막 단계는 세 가지 NFS 내보내기에 대한 하위 종속성을 생성하는 것입니다. 즉, Datakeeper 미러 및 IP로 완료된 모든 NFS 내보내기는 로드 밸런서에 의존합니다. 활성 노드에서 심각한 문제가 발생하면 이러한 모든 리소스가 다른 작동 중인 노드로 장애 조치됩니다.

위의 Lifekeeper GUI에서 완성된 계층 구조. 아래는 NFS 내보내기, IP, 파일 시스템 및 DataKeeper 복제 볼륨을 로드 밸런서 리소스의 자식으로 보여주는 확장된 GUI 보기를 보여줍니다.

이것은 SIOS LifeKeeper를 사용하는 방법의 한 예일 뿐입니다. 하늘빛 간단한 NFS 클러스터를 보호합니다. 보호해야 하는 모든 비즈니스 크리티컬 애플리케이션에도 동일한 개념이 적용됩니다. Azure Load Balancer(내부 또는 외부)가 현재 애플리케이션을 호스팅하고 있는 노드를 결정할 수 있도록 SIOS에서 제공하는 Load Balancer ARK를 활용하기만 하면 됩니다.

디즈니와 픽사의 소울에서 주인공 조 가드너(목소리: Jamie Foxx)는 전문 재즈 피아니스트가 되는 것이 꿈이었습니다.그러나 여러 번의 시도에도 불구하고 어머니는 실망스럽게도 꿈에서 멀어져 ‘중년의 중학교 밴드 선생님’으로 살아가고 있다. 그러나 “마지막 순간에 재즈의 전설 도로시아 윌리엄스의 4중주단에서 연주할 수 있는 기회가 생겨서 그의 꿈이 드디어 현실이 되는 것 같습니다.그것은 “운명적인 실수로 영혼이 관심, 성격, 기발함을 얻는 위대한 비포(Great Before)로 보내지고 조는 지상 생활에 관심이 없는 고대 영혼 “22”와 강제로 일하게 될 때까지입니다. “너무 늦기 전에 어떻게든 지구로 돌아가기 위해( D23.com ).” Disney and Pixar’s Soul은 흥미롭고 공감할 수 있는 캐릭터, 유머러스하고 묘사적이며 때로는 혼란스러울 정도로 관련이 있는 삶, 목적, 삶을 다룬 훌륭한 영화입니다.하지만 부자가 있는 영화이기도 하다. 리더십 수업 , 생활 수업 및 고가용성 수업.

Disney와 Pixar’s Soul의 고가용성에 대한 7가지 생각.

1. 무슨 일이 일어나고 있는지 주목하라

Disney와 Pixar의 Soul에서 Joe는 그의 꿈의 공연을 펼칩니다.그러나 Joe가 걷기 시작하고 좋은 소식을 나누기 시작하면서 그는 휴대전화에 너무 빠져서 거리로 걸어가다가 1톤의 벽돌 아래에 거의 짓눌릴 뻔했습니다. 그런 다음 그는 열려 있지만 명확하게 표시된 맨홀을 향해 위험하게 방황합니다.고가용성을 위한 교훈은 무엇입니까? 주의하십시오.모니터링 및 복구 솔루션의 경고 및 오류 메시지에 주의하십시오.호스팅 제공업체의 변경 사항, 특히 공급업체, 파트너 및 보안 팀의 중요한 알림에 주의하십시오.경고 및 경고는 이유가 있습니다. 경고를 보고 적절한 조치를 취하지 않거나 해결하지 않으면 깊은 구멍에 빠질 수 있습니다.

2. 구멍에 빠지지 마십시오

경고를 무시하거나 무시하던 조는 열린 맨홀에 빠져 영혼이 되어 마침내 종말을 맞이합니다.이것은 즉시 그의 꿈과 계획을 바꿉니다.그렇다면 귀사는 어떤 구멍에 빠질 수 있습니까?적용 범위의 허점, 버전 관리의 허점, 유지 관리 계획 및 현실의 허점 또는 벤더 대응의 블랙홀과 같은 기업의 경로에 숨어 있는 열린 구멍이 있습니까?환경을 둘러보십시오. 명백한 단일 실패 지점을 넘어 어떤 구멍에 빠질 수 있습니까?보호되지 않는 중요 애플리케이션, 팀 간의 커뮤니케이션 격차 또는 프로세스 및 위기 관리의 구멍과 관련된 열린 구멍이 있다는 경고가 있습니까?손상을 일으키거나 끝낼 수 있는 구멍에 빠지지 마십시오. 고가용성 .

3. 고가용성을 서두르지 마십시오.

영혼이 된 후 조는 자신의 몸으로 돌아가려고 적극적으로 노력하기 시작합니다.그가 22와 짝을 이루었을 때, 그녀는 그를 Moonwind에게 데려가 그의 시체를 찾는 데 도움을 주기로 동의합니다.그러나 조는 문윈드의 주의에도 불구하고 그의 몸으로 다시 뛰어들고 싶어진다.급하게 그와 22명은 모두 땅으로 떨어지지만 조는 고양이의 몸으로, 22명은 그의 몸으로 돌아간다.우리가 인내하지 않으면 Joe처럼 점프가 너무 빨리 일어나 결국 위태롭거나 더 나쁜 상황에 처하게 됩니다.우리는 고양이의 몸이 아닐 수도 있지만, HA를 유지하는 데 필요한 최상의 위치와도 거리가 멀 수도 있습니다.너무 빨리 점프하는 것은 다음과 같습니다.

1. 아키텍처 또는 전체론적 솔루션 없이 소프트웨어 배포
2. QA에서 테스트하지 않고 프로덕션에 배포
3. 클라우드 또는 HA가 의미하는 클라우드에 대한 이해 없이 클라우드에 배포
4. 일정에 따라 프로덕션에 배포하고 승인 테스트를 완료하지 않음
5. 애플리케이션 모니터링 및 오케스트레이션을 위해 특별히 구축된 상용 등급 솔루션 없이 배포

4. 너무 빨리 종료하지 마십시오. 고가용성은 결코 쉬운 일이 아닙니다.

젊은 트롬본 연주자 코니는 선생님의 아파트에 찾아와 좌절감을 느끼고 그만두고 싶어합니다.그녀는 Joe(Joe의 몸에서는 실제로 22세)에게 자신이 좌절하고 있으며 포기하고 그만두고 싶다고 말하면서 시작합니다.그러나 잠시 후 그녀는 트롬본으로 마지막 곡을 연주하고 그만두기에는 너무 이르다는 것을 깨달았습니다.고가용성에서 우리는 모두 Connie와 매우 비슷합니다. 때때로 어려움은 우리가 밧줄의 끝에 있고 그만두고 싶은 것처럼 느끼게 만듭니다.때때로 정전으로 인해 우리는 수건을 던져야 할 때라고 확신하게 됩니다. 너무 빨리 종료하지 마십시오.HA는 결코 쉽지 않습니다!그러나 가동 중지 시간을 끝내기 위해 노력을 중단하는 것은 항상 너무 이르므로 Connie와 마찬가지로 우리는 계속 유지해야 할 수도 있습니다.이것은 나를 다음 수업으로 이끕니다.

5. 당신은 모든 것을 시도하지 않았습니다

영화에서 22는 아직 살지 않은 영혼입니다.그녀는 그녀에게 불꽃을 주기 위해 가능한 모든 것을 시도했다고 믿지만, 그녀가 Joe의 몸에 빠지자 그녀는 시도하지 않은 것이 많다는 것을 깨닫게 됩니다.고가용성 솔루션을 만들 때 모든 것과 모든 제품을 사용해 본 것처럼 쉽게 느껴질 수 있지만 대부분은 그렇지 않을 가능성이 큽니다.새로운 관점, 또는 새로운 시각으로 도전과 문제를 바라보는 것은 시스템과 기업의 가용성을 향상시키는 데 도움이 될 수 있습니다.

고가용성을 위해 시도할 몇 가지 사항은 다음과 같이 간단할 수 있습니다.

1. 주요 모니터링 지표에 대한 추가 알림 설정
2. 분석을 추가합니다.
3. 정기적인 유지 관리 수행(패치, 업데이트, 보안 수정)
4. 프로세스 문서화
5. 운영 플레이북 문서화
6. 커뮤니케이션 라인 개선
7. 정기적인 유지 관리 수행

다른 아이디어는 더 많은 작업, 연구, 시간 및 돈이 필요할 수 있지만 과거에 탐색한 적이 없다면 가치가 있을 수 있습니다.

더 많은 시간과 노력으로 고가용성을 개선하는 방법은 다음과 같습니다.

1. 해킹 및 해결 방법을 제거합니다.
2. 견고하고 반복 가능한 솔루션 아키텍처 생성
3. 상업화 및 목적 구축
4. 컨설턴트 고용
5. 아키텍처 감사 및 문서화
6. VM을 확장하십시오. CPU, 메모리 및 IOP
7. 영역 또는 지역 수준에서 추가 중복성 추가

6. 더 많은(그리고 더 나은) 질문하기

밋튼 씨인 조가 실수로 머리카락 한가운데를 자른 후 미튼과 조는 조의 이발사인 데즈를 만나러 여행을 떠나야 합니다.Joe가 Dez와 함께 이발소에 있는 동안 그들은 목적, 삶, 실존적 존재 등에 대해 대화를 나누기 시작합니다.머리를 자른 후 22는 Dez에게 왜 이전에는 Dez의 삶에 대해 이런 대화를 한 적이 없었는지 묻습니다.Dez는 한 번도 물어본 적이 없다고 대답합니다.때때로 우리는 솔루션, 클라우드 또는 사내 구축형 방법, 언어 및 아키텍처, 다른 사람들에게 우리가 하고 있는 일을 말하는 데 너무 집중하다 보니 완전히 새로운 세상을 열 수 있는 질문을 하는 것을 잊어버릴 수 있습니다.Joe가 질문을 하면서 Dez와 자신에 대해 더 많이 알게 되었습니다.아마도 더 나은 HA를 위한 교훈은 솔루션, 아키텍처, 비즈니스 목표 및 과제, 최종 고객 목표, 팀, 더 큰 그림 내에서 우리의 역할과 책임에 대해 더 많은 질문을 하기 시작하는 것입니다.

가용성을 높이기 위한 몇 가지 간단한 질문은 다음과 같습니다.

1. 내일 재해가 발생하면 어떤 시스템, 프로세스, 제품 또는 솔루션이 원인이 될까요?
2. 보호해야 할 가장 중요한 것은 무엇입니까?애플리케이션, 데이터, 메타데이터, 위의 모든 것?
3. 애플리케이션과 데이터베이스가 견딜 수 있는 RPO는 무엇입니까?
4. 고객이 용납하지 않는 것은 무엇입니까?
5. 내가 무엇을 놓치고 있습니까?
6. 이 아키텍처는 어디에 문서화되어 있습니까?
7. 내가 무엇을 이해하지 못합니까?

7. 인내가 결실을 맺는다

테리가 말합니다.그레이트 비욘드의 참가자를 추적하는 임무를 맡은 테리는 도착해야 하거나 도착해야 하는 영혼의 수를 세심하게 세고 있습니다.Joe가 Great Before로 우회한 후 Terry는 잃어버린 영혼을 찾고 집계를 수정하기로 결심합니다. 그가 작업을 시작했을 때, 그는 눈으로 볼 수 있을 만큼 높이 뻗은 파일 캐비닛의 긴 복도에 있습니다.그러나 잠시 후 그는 Joe의 파일을 발견하고 Joe가 허점을 발견했고 이것이 카운트가 중단된 이유를 발견합니다.Terry가 보여준 동일한 인내는 더 높은 가용성의 영역에서도 보상을 받을 것입니다.엄청난 불확실성, 수많은 로그 파일, 그리고 가능한 실패 시나리오의 바다에 직면하여 문제가 발생하기 전에 발견하고 해결하거나 문제가 발생한 후 이를 효과적으로 분석 및 수정하기 위한 인내의 순간은 우리를 더 나은 방향으로 이끌 것입니다. 우리가 원하는 결과.마찬가지로 근면과 인내의 부족은 새로운 소프트웨어가 있는 새로운 환경에서도 동일한 문제가 나중에 다시 나타날 가능성이 있음을 의미합니다.

영화 소울이 끝나자 조는 위대한 비포로 돌아가 22를 찾아 그녀의 지구를 통과하고 뛰어들도록 설득합니다.그녀는 Joe와 함께 지상에 떨어졌을 때를 회상하며 다시 한 번 뛰어듭니다.내 아이들을 실망스럽게도 이 영화는 22세가 그녀의 삶에 대해 어떻게 생각하는지, 또는 뒤따르는 새로운 기회에 대해 설명하지 않고 끝납니다.그녀는 다음에 일어날 일에 대한 기대와 함께 위대한 이전에서 단순히 도약합니다.아마도 우리도 뛰어들 수 있는 순간에 서 있을 것입니다. “Great Before”의 순간이자 올해를 더 높은 가용성으로 만들 수 있는 기회입니다.

– Cassius Rhue, 고객 경험 부사장