자료실

가용성 공식 – 고 가용성 솔루션

12월 9, 2018 by Jason Aw Leave a Comment

가용성 공식

가용성 방정식에 익숙합니까? 간단히 말해서,이 방정식은 애플리케이션을 가용성으로 복원하는 데 필요한 총 시간이 애플리케이션에 문제가 발생했음을 감지하는 데 필요한 시간과 복구 조치를 수행하는 데 필요한 시간을 합한 것과 같습니다.

T_RESTORE = T_DETECT + T_RECOVER

고 가용성 솔루션의 주요 개념

이 수식에서는 고 가용성 (HA)의 핵심 개념 인 클러스터링, 문제 감지 및 후속 복구를 소개합니다. HA 솔루션은 비즈니스 응용 프로그램 구성 요소의 상태를 모니터링합니다. 문제가 발견되면 이러한 솔루션은 서비스를 복원합니다. 고 가용성 솔루션을 배포하는 목적은 다운 타임을 최소화하는 것입니다. 탐지 및 복구 시간을 줄이는 것은 배포하도록 선택한 모든 HA 솔루션의 두 가지 중요한 작업입니다. 오늘날의 응용 프로그램은 서버, 저장소, 네트워크 인프라 등 기술 조합입니다. HA 옵션을 검토 할 때 각 솔루션이 모든 중단 유형을 감지하고 복구하는 데 사용하는 기술을 이해해야합니다. 각 기술은 서비스 복원 시간에 직접적인 영향을 미칩니다.

로컬 검색 및 복구

고 가용성 솔루션은 간단합니다. 가능한 가장 빠른 복원 시간을 제공하는 데 중요한 기술 중 하나가 로컬 탐지 및 복구 (서비스 수준 문제 감지 및 복구라고도 함)입니다. 기본 클러스터링 솔루션에서는 서버가 연결됩니다. 서버 실패시 하나 이상의 서버가 다른 서버의 작업을 인계받을 수 있도록 구성됩니다. 클러스터의 서버 노드는 하트 비트 신호라고도하는 작은 데이터 패킷을 계속해서 보내고 이들이 "활성"상태임을 나타냅니다. 간단한 클러스터 환경에서 한 서버가 하트 비트 생성을 중지하면 다른 클러스터 구성원은이 서버가 다운 된 것으로 간주합니다. 그런 다음 해당 서버의 작동 도메인에 대한 책임을 인수하는 프로세스를 시작합니다. 이 접근 방식은 서버 수준에서 실패를 감지하는 데 적합합니다. 그러나 문제로 인해 하트 비트 신호가 중단되거나 중단되지 않으면 서버 수준의 탐지가 적절하지 않습니다. 그보다는 실제로 정전의 정도와 영향을 확대 할 수 있습니다. 예를 들어, Apache 프로세스가 중단되면 서버가 여전히 하트 비트를 보낼 수 있습니다. 웹 서버 서브 시스템이 주요 기능 수행을 중단하더라도. 동일한 서버 나 다른 서버에서 Apache 하위 시스템을 다시 시작하는 대신 기본 서버 수준 클러스터링 솔루션은 백업 서버에서 오류가 발생한 서버의 전체 소프트웨어 스택을 다시 시작하므로 사용자가 중단되고 복구 시간이 연장됩니다.

어떻게 작동 하는가?

로컬 검색 및 복구를 사용하는 고급 클러스터링 솔루션은 개별 클러스터 서버 내에 상태 모니터링 에이전트를 배포하여 파일 시스템, 데이터베이스, 사용자 수준 응용 프로그램, IP 주소 등과 같은 개별 시스템 구성 요소를 모니터링합니다. 이러한 에이전트는 모니터링되는 구성 요소에 특정한 휴리스틱을 사용합니다. 따라서 에이전트는 운영 문제를 예측하고 감지 한 다음 가장 적절한 복구 작업을 수행 할 수 있습니다. 대부분의 경우 가장 효율적인 복구 방법은 동일한 서버에서 문제가되는 하위 시스템을 중지했다가 다시 시작하는 것입니다. 동일한 물리적 서버 내에서 복구를 사용 가능하게함으로써 응용 프로그램을 사용자 가용성으로 복원하는 시간을 크게 줄일 수 있습니다. 또한 단순히 서버 수준의 하트 비트를 관찰하는 것보다 세분화 된 수준에서 오류를 감지합니다. Linux 용 SteelEye Protection Suite (예 : SIOS)와 같은 솔루션은 사용자 환경에 대해 이러한 수준의 탐지 및 복구를 제공합니다. 배포하는 HA 솔루션이 로컬 탐지 및 복구를 지원할 수 있는지 확인하십시오. 귀사의 프로젝트에 고 가용성 솔루션을 즐기시겠습니까? 우리와 함께 확인하십시오. 더 많은 참고 문헌이 필요합니다. 여기에는 성공 사례가 있습니다. Linux 클러스터링의 허락을 받아 재현

12 고 가용성 솔루션을 선택하기위한 점검 목록 항목

12월 6, 2018 by Jason Aw Leave a Comment

고 가용성 솔루션을 선택하기위한 12 가지 검사 목록 항목

고 가용성 솔루션을 선택할 때 몇 가지 기준을 고려해야합니다. 이는 솔루션의 총 비용에서 클러스터 구성 및 관리의 용이성, 하드웨어 및 소프트웨어에 대한 특정 제한 사항까지 다양합니다. 이 게시물은 가장 중요한 체크리스트 항목 중 12 개에 간단히 적용됩니다.

1. 표준 OS 및 응용 프로그램 버전 지원

OS, 데이터베이스 또는 응용 프로그램 소프트웨어의 엔터프라이즈 또는 고급 버전이 필요한 솔루션은 범용 서버 환경으로 전환 할 경우의 비용 이점을 크게 줄일 수 있습니다. 적절한 HA 미들웨어를 배포하십시오. 이 방법을 사용하면 표준 버전의 응용 프로그램과 OS를 고 가용성으로 사용할 수 있습니다. 동시에 비즈니스 환경의 가동 시간 요구 사항을 충족하십시오.

2. 다양한 데이터 저장 장치 구성 지원

HA 클러스터를 전개 할 때, 보호 된 응용 프로그램이 필요로하는 데이터는 응용 프로그램을 서비스해야하는 모든 시스템에서 사용 가능해야합니다. 이 데이터는 데이터 복제를 통해 공유 SCSI 또는 파이버 채널 저장소를 사용하거나 NAS 장치를 사용하여 공유 할 수 있습니다. 어떤 방법으로 배포하든, 사용하는 HA 제품은 비즈니스 요구 사항에 따라 변경할 수 있도록 모든 데이터 구성을 지원할 수 있어야합니다.

삼. 이기종 솔루션 구성 요소 사용 기능

일부 HA 클러스터링 솔루션은 클러스터 내의 모든 시스템이 동일한 구성을 요구합니다. 이 요구 사항은 클러스터링 기술이 서버 또는 스토리지를 차별화하고 OS 벤더 사이에서 지원해야하는 구성을 제한하려는 하드웨어 관련 솔루션에 공통적으로 적용됩니다. 이 제한 사항은 확장 된 서버를 임시 백업 노드로 배포하고 클러스터 배포에서 기존 하드웨어를 다시 사용할 수있는 능력을 제한합니다. 동일하게 구성된 서버를 배포하는 것이 귀하의 필요에 맞는 올바른 선택 일 수 있지만 결정은 귀하의 HA 솔루션 제공 업체에 의해 결정되어서는 안됩니다.

4. 클러스터 내 3 개 이상의 노드 지원

클러스터에서 지원할 수있는 노드 수는 확장 성의 중요한 척도입니다. 엔트리 레벨 HA 솔루션은 대개 액티브 / 패시브 모드에서 하나의 2 노드 클러스터로 제한합니다. 이 구성은 대기 서버 추가를 통한 가용성 향상을 제공하지만 여전히 응용 프로그램 중단 시간에 노출 될 수 있습니다. 2 노드 클러스터 구성에서 어떤 이유로 서버 하나가 작동 중지 된 경우 나머지 서버는 단일 실패 지점이됩니다. 3 개 이상의 노드를 클러스터링하면 더 높은 수준의 보호 기능을 제공 할 수 있습니다. 동시에 확장 성이 뛰어난 구성을 구축 할 수도 있습니다.

5. 액티브 / 액티브 및 액티브 / 스탠바이 구성 지원

프로젝트에 적합한 고 가용성 솔루션을 선택하는 것이 중요합니다. 활성 / 대기 구성에서 한 서버는 유휴 상태이며 클러스터 구성원의 작업 부하를 인계받습니다. 이 설정에는 컴퓨팅 리소스 투자를 제대로 활용하지 못하는 단점이 있습니다. IT 지출에서 최대 이익을 얻으려면 클러스터 노드가 활성 / 활성 구성에서 실행될 수 있는지 확인하십시오.

6. 노드 및 개별 서비스 수준에서의 문제 탐지

모든 HA 소프트웨어 제품은 클러스터 서버 기능의 문제점을 감지 할 수 있습니다. 이 작업은 클러스터 구성원이 신호 전달을 중지하면 클러스터 내의 서버간에 하트 비트 신호를 보내고 복구를 시작하여 수행됩니다. 그러나 고급 HA 솔루션은 또 다른 문제를 감지 할 수 있습니다. 개별 프로세스 나 서비스가 사용할 수 없게 만들지 만 서버가 하트 비트 신호를 보내거나 응답하지 않게하는 문제가 발생할 때 발생합니다. HA 소프트웨어의 주요 기능은 최종 사용자가 응용 프로그램을 사용할 수 있는지 확인하는 것이므로 이러한 서비스 수준의 중단을 감지하고 복구하는 것이 중요한 기능입니다. HA 솔루션이 노드 및 서비스 레벨 문제를 모두 감지 할 수 있는지 확인하십시오.

7. 노드 내 및 노드 간 복구 지원

클러스터 노드와 노드 내에서 복구 작업을 수행하는 기능 또한 중요합니다. 노드 간 복구에서 한 노드가 다른 노드에 대한 책임의 전 영역을 담당합니다. 시스템 레벨 하트 비트가 누락되면 하트 비트를 보내야하는 서버는 작동 불능으로 간주되고 다른 클러스터 구성원은 복구 조작을 시작합니다. 노드 내 또는 로컬 복구의 경우 실패한 시스템 서비스는 먼저 실행중인 서버 내에서 복원을 시도합니다. 이 작업은 일반적으로 서비스 및 종속 시스템 리소스를 중지하고 다시 시작하여 수행합니다. 이 복구 방법은 훨씬 빠르며 다운 타임을 최소화합니다.

8. 서버 측 복구의 클라이언트 연결에 대한 투명성

애플리케이션 또는 전체 노드의 서버 측 복구는 클라이언트 측 사용자에게 투명해야합니다. 가상화 된 IP 주소 또는 서버 이름의 사용, 복구 중 실제 컴퓨팅 엔티티로의 가상 컴퓨팅 리소스 매핑 및 네트워크 라우팅 테이블 자동 업데이트를 통해 시스템이 복구 된 응용 프로그램과 데이터에 액세스하는 데 클라이언트 시스템을 변경하지 않아도됩니다. 복구 된 응용 프로그램에 액세스하기 위해 수동으로 클라이언트 측 구성을 변경해야하는 솔루션은 복구 시간을 크게 늘립니다. 필요한 상호 작용으로 인해 추가 오류가 발생할 수 있습니다. 복구는 서버와 클라이언트 모두에서 자동화되어야합니다.

9. 계획되고 계획되지 않은 다운 타임에 대한 보호

계획되지 않은 서비스 중단에 대한 보호 기능 외에도 배포하는 HA 솔루션은 유지 관리 활동으로 인한 중단 시간을 줄이기위한 관리 도구로 사용할 수 있어야합니다. 클러스터 구성원간에 응용 프로그램을 주문형으로 이동할 수있는 기능을 제공함으로써 응용 프로그램과 사용자를 첫 번째 유지 관리를 수행하는 동안 두 번째 서버로 마이그레이션 할 수 있습니다. 따라서 최종 사용자가 IT 리소스를 사용할 수없는 유지 관리 기간이 필요하지 않습니다. HA 솔루션이 클러스터 노드간에 응용 프로그램과 필요한 리소스를 수동 (요청시)으로 이동하는 간단하고 안전한 방법을 제공하는지 확인하십시오.

10. 일반적인 비즈니스 기능을위한 선반 보호

평가할 모든 HA 솔루션에는 파일 시스템, IP 주소, 데이터베이스, 응용 프로그램 등 특정 시스템 자원의 상태를 모니터하도록 설계된 테스트 및 지원되는 에이전트 또는 모듈이 포함되어야합니다. 이러한 모듈을 복구 모듈이라고도합니다. 공급 업체가 제공 한 모듈을 배포하면 공급 업체와 다른 고객이 이미 수행 한 런타임 모두에서 이익을 얻을 수 있습니다. 또한 이러한 솔루션 구성 요소를 지속적으로 지원하고 유지 관리 할 수 있습니다.

11. 맞춤형 비즈니스 애플리케이션을위한 보호 기능을 쉽게 통합 할 수있는 기능

기업에 보호 조치를 원하지만 공급 업체에서 제공 한 복구 모듈이없는 응용 프로그램이있을 수 있습니다. 따라서 HA 솔루션의 보호 스키마에 비즈니스 애플리케이션을 쉽게 통합 할 수있는 방법이 필요합니다. 응용 프로그램을 수정하지 않고 특히 공급 업체 특정 API를 포함하지 않고이 작업을 수행 할 수 있어야합니다. 애플리케이션을 보호하기위한 예제와 단계별 프로세스를 제공하는 소프트웨어 개발자 키트가 있어야합니다. 또한 필요한 경우 제공 업체가 제공하는 지원 서비스도 함께 제공됩니다.

12. 클러스터 구축 및 관리의 용이성

HA 클러스터를 둘러싼 공통된 신화는 배포 및 관리에 비용이 많이 들고 복잡하다는 것입니다. 이것은 반드시 사실 일 필요는 없습니다. 초기 클러스터 구성을 지원하려면 클러스터 관리 인터페이스를 마법사 기반으로 사용해야합니다. 새 요소가 클러스터에 추가 될 때 자동 요소 발견이 포함되어야합니다. 마찬가지로 전체 클러스터의 상태를 한 눈에 모니터링 할 수 있어야합니다. 마지막으로 모든 클러스터 메타 데이터는 HA 방식으로 저장해야합니다. 손상 또는 중단으로 인해 전체 클러스터가 분리 될 수있는 클러스터 내의 단일 쿼럼 디스크가 아닙니다. 이 체크리스트의 기능을 살펴봄으로써 특정 HA 요구에 가장 적합한 결정을 내릴 수 있습니다. 고 가용성 솔루션을 선택하는 것은 로켓 과학이 아닙니다. Linuxclustering의 허가를 받아 복제했습니다.

실시간 복제를 지원하는 데 얼마나 많은 대역폭이 필요한지 알고 있습니까?

12월 5, 2018 by Jason Aw Leave a Comment

실시간 복제를 지원하는 데 얼마나 많은 대역폭이 필요합니까?

다중 사이트 또는 WAN (Wide Area Network) 구성에서 데이터를 복제하려면 먼저 한 가지 중요한 질문에 대답해야합니다. 파티션을 성공적으로 복제하고 원본 파티션이 미러링 상태가되도록 충분한 대역폭이 있습니까? 하루 종일 업데이트 되었습니까? 미러를 미러링 상태로 유지하는 것이 중요합니다. 파티션 전환은 미러가 미러링 상태 일 때만 허용됩니다.

따라서 실시간 복제를 지원하는 대역폭의 양이 네트워크 대역폭 요구 사항을 결정하는 중요한 초기 단계입니다. 데이터를 복제하는 데 필요한 네트워크 대역폭의 양을 나타내는 값인 변화율을 어떻게 측정 할 수 있습니까?

기본 변화율 확립

먼저이 명령을 사용하여 미러링 할 파일 또는 파티션의 기본 일일 변동률을 결정하십시오. 예를 들어, / dev / sda3에 대해 하루에 기록 된 데이터의 양을 측정하려면 다음 명령을 실행하십시오 : MB_START =`awk '/ sda3 / {print $ 10 / 2 / 1024}'/ proc / diskstats `24 시간 기다린 후 다음 명령을 실행하십시오 : MB_END =`awk '/ sda3 / {print $ 10 / 2 / 1024}'/ proc / diskstats` 일일 변경 비율은 메가 바이트 단위로 MB_END – MB_START입니다. 다양한 네트워크 연결을 통해 누를 수있는 데이터의 양은 다음과 같습니다.

T1 (1.5Mbps) : 14,000MB / 일 (14GB)
T3 (45Mbps) : 410,000MB / day (410GB)
기가비트 (1Gbps) : 5,000,000MB / 일 (5TB)

변화의 구체적인 비율 확립

다음은 실시간 복제를 지원하기 위해 대역폭을 계산하는 방법입니다. 상세한 변화율을 측정해야합니다. 이 데이터를 수집하는 가장 좋은 방법은 일정 기간 (예 : 1 일) 동안 디스크 쓰기 활동을 기록하여 최대 디스크 쓰기 기간을 결정하는 것입니다. 이렇게하려면 시스템의 타임 스탬프를 기록한 다음 / proc / diskstats 덤프를 기록하는 cron 작업을 작성하십시오. 예를 들어 2 분마다 디스크 통계를 수집하려면 다음 링크를 / etc / crontab에 추가하십시오. * / 2 * * * * root (date; cat / proc / diskstats) >> /path_to/filename.txt (예 : 1 일, 1 주일), cron 작업을 비활성화하고 결과 / proc / diskstats 출력 파일을 안전한 위치에 저장하십시오.

변화율 데이터의 분석 및 그래프 작성

다음으로 상세한 변화율 데이터를 분석해야합니다. 이 작업을 위해 roc-calc-diskstats 유틸리티를 사용할 수 있습니다. 이 유틸리티는 / proc / diskstats 출력 파일을 사용하고 데이터 세트의 디스크 변경 비율을 계산합니다. 이 유틸리티를 실행하려면 다음 명령을 사용하십시오. # ./roc-calc-diskstats <interval> <start_time> <diskstats-data-file> [dev-list] 예를 들어 다음은 디스크 별 피크 I / O 정보)를 출력 파일 results.txt에 추가합니다. # ./roc-calc-diskstats 2m "Jul 22 16:04 :01 "/root/diskstats.txt sdb1, sdb2, sdc1> results.txt 다음은 results.txt 파일의 샘플 결과입니다. 샘플 시작 시간 : Tue Jul 12 23:44 :01 2011 샘플 종료 시간 : Wed Jul 13 23:58 :01 2011 샘플 간격 : 120 초 # 샘플 : 727 샘플 길이 : 87240 초 (파일에서 원시 시간 : Tue Jul 12 23:44 :01 EST 2011, Wed Jul 13 23:58 :01 EST 2011) 장치 dm-31, dm-32, dm-33, dm-4, dm-5, 전체 dm-31 피크의 변화율 : 0.0 B / s (@ bue 7 월 12 일 23:44 :01 2011) 평균 : 0.0 B / s (0.0 b / s) dm-32 피크 : 398.7 KB / s (3.1 Mb / s) (@ Wed Jul 13 19:28 :01 2011) 평균 : 19.5 KB / s (156.2 Kb / s) dm-33 피크 : 814.9 KB / s (6.4 Mb / s) (@ Wed Jul 13 23:58 :01 2011) 평균 : 11.6 KB / s (92.9 Kb / s) dm-4 피크 : 185.6 KB / s (1.4 Mb / s) (@ Wed Jul 13 15:18 :01 2011) 평균 : 25.7 KB / s (205.3 Kb / s) dm-5 피크 : 2.7 MB / s (21.8 Mb / s) (@ Wed Jul 13 10:18 :01 2011) average : 293.0 KB / s (2.3 Mb / s) 총 피크 : 2.8 MB / s (22.5 Mb / s) (@ Wed Jul 13 10:18 :2011 년 1 월) average : 349.8 KB / s (2.7 Mb / s) 시간 경과에 따른 특정 대역폭 요구 사항을 이해하는 데 도움이되도록 자세한 변경 속도 데이터를 그래프로 나타낼 수 있습니다. 다음은 results.csv에 그래프 데이터를 덤프합니다 (results.txt에 요약을 덤프 함). # export OUTPUT_CSV = 1 # ./roc-calc-diskstats 2m "Jul 22 16:04 :01 "/root/diskstats.txt sdb1, sdb2, sdc1 2> results.csv> results.txt SIOS는 roc-calc의 데이터로 덮어 쓸 수있는 샘플 데이터가 들어있는 템플릿 스프레드 시트 diskstats-template.xlsx를 만들었습니다 -diskstats. 다음 일련의 이미지는 스프레드 시트를 사용하는 과정을 보여줍니다.

results.csv를 열고 전체 열을 포함하여 모든 행을 선택합니다.

diskstats-template.xlsx를 열고 diskstats.csv 워크 시트를 선택하십시오.

셀 1-A에서 마우스 오른쪽 버튼을 클릭하고 복사 된 셀 삽입을 선택합니다.
복제에 할당 한 대역폭의 양 (초당 메가 비트)을 반영하도록 워크 시트의 왼쪽 하단을 향해 셀의 대역폭 값을 조정합니다 (다음 그림 참조). 오른쪽의 셀은 수집 된 원시 데이터와 일치하도록 초당 바이트로 자동 변환됩니다.

다음 행 및 열 번호를 메모하십시오.

- 합계 (다음 그림의 행 6)
- 대역폭 (다음 그림의 행 9)
- 마지막 데이터 점 (다음 그림의 열 R)

대역폭 대 ROC 워크 시트를 선택하십시오.

그래프를 마우스 오른쪽 버튼으로 클릭하고 데이터 선택을 선택하십시오.
데이터 원본 선택 대화 상자에서 범례 항목 (계열) 목록에서 대역폭을 선택한 다음 편집을 클릭합니다.

시리즈 편집 대화 상자에서 시리즈 값 필드에 다음 구문을 사용하십시오. = diskstats.csv! $ B $ <row> : $ <final_column> $ <row> 다음 그림은 스프레드 B9에서 R9까지의 연속 값을 보여줍니다 .

확인을 클릭하여 시리즈 편집 상자를 닫습니다.
데이터 원본 선택 상자에서 범례 항목 (계열) 목록에서 ROC를 선택한 다음 편집을 클릭합니다.

시리즈 편집 대화 상자에서 시리즈 값 필드에 다음 구문을 사용하십시오. = diskstats.csv! $ B $ <row> : $ <final_column> $ <row> 다음 그림은 스프레드 B6에서 R6까지의 계열 값을 보여줍니다 .

확인을 클릭하여 시리즈 편집 상자를 닫은 다음 확인을 클릭하여 데이터 소스 선택 상자를 닫습니다.

대역폭 대 ROC 그래프가 업데이트됩니다. 결과를 분석하여 데이터 복제를 지원할 충분한 대역폭이 있는지 확인하십시오.

다음 단계

변경 비율이 사용 가능한 대역폭을 초과하는 경우 복제 솔루션이 최적의 성능을 발휘할 수 있도록 다음 사항 중 일부를 고려해야합니다.

복제 솔루션 또는 네트워크 하드웨어에서 압축을 사용합니다. Linux 용 SteelEye Protection Suite의 일부인 Linux 용 DataKeeper는 이러한 유형의 압축을 지원합니다.
복제 할 필요가없는 임시 데이터 및 스왑 파일을위한 복제되지 않은 로컬 저장소를 만듭니다.
복제되는 데이터의 양을 줄입니다.
네트워크 용량을 늘리십시오.

실시간 복제를 지원하기 위해 대역폭을 계산하는 것과 같은 빠른 방법을 보려면 Linux 클러스터링의 허가로 복제 된 블로그를 읽어보십시오.

Linux를위한 SAP 고 가용성 솔루션

12월 3, 2018 by Jason Aw Leave a Comment

Linux를위한 SAP 고 가용성 솔루션

강력하고 쉬운 SAP 환경을위한 고 가용성 / 재해 복구 솔루션을 구현하고 싶습니까? 그렇다면 SIOS Technologies의 Linux 용 SteelEye Protection Suite (SPS)를 살펴보고 싶을 것입니다. SPS는 모든 서버 또는 저장소 구성에서 작동하는 통합 된 고 가용성 및 데이터 복제 기능을 제공합니다. SAP에 대한 지원은 스크립팅 또는 사용자 정의가 필요없이 즉시 사용할 수 있습니다.

Linux 용 SPS는 최근 SAP에서 "SAP NetWeaver 고 가용성 클러스터 730 인증"(NW-HA-CLU 730)에 대해 공식 인증을 받았습니다. SAP 용 인증 HA 솔루션 목록은 http://scn.sap.com에서 확인할 수 있습니다. / docs / DOC-31701 SAP 고 가용성 솔루션에 대한 자세한 내용은 Linux 용 노트를 작성하십시오. Linuxclustering의 허가를 받아 복제했습니다.

공유 스토리지가없는 2 노드 MySQL 클러스터 생성 방법 – 2 부

11월 30, 2018 by Jason Aw Leave a Comment

단계별 : 공유 스토리지가없는 2 노드 MySQL 클러스터 생성 방법, 2 부

이전 포스트에서는 비공유 스토리지 구성을 사용하여 MySQL 클러스터를 실행하는 장점을 소개했습니다. 또한 Linux 용 데이터 복제 및 SteelEye Protection Suite (SPS)를 사용하여 클러스터를 설정하는 과정을 시작했습니다. 이 글에서는 공유 스토리지가없는 2- 노드 MySQL 클러스터 생성 프로세스를 완료합니다. 시작하자.

통신 경로 작성

이제 SteelEye LifeKeeper GUI에 액세스하십시오. LifeKeeper는 Linux 용 SPS의 통합 구성 요소입니다. LifeKeeper GUI는 Java 기반 웹 브라우저에서 기본 Linux 응용 프로그램 또는 애플릿으로 실행할 수있는 Java 기반 응용 프로그램입니다. (GUI는 콜백이있는 Java RMI를 기반으로하므로 호스트 이름을 해석 할 수 있어야합니다. 그렇지 않으면 Java 115 또는 116 오류가 발생할 수 있습니다.) GUI 응용 프로그램을 시작하려면 클러스터 노드 중 하나에서 다음 명령을 입력하십시오. / opt / LifeKeeper / bin / lkGUIapp & 또는 웹 브라우저에서 GUI 애플릿을 열려면 http : // <hostname> : 81로 이동하십시오.

첫 번째 단계는 하트 비트 중복성을 위해 각 주 서버와 각 대상 서버 사이에 최소한 두 개의 TCP 통신 (Comm) 경로가 있는지 확인하는 것입니다. 이렇게하면 한 통신 회선의 장애로 인해 스플릿 블로 브 상황이 발생하지 않습니다. 주 서버의 경로를 확인하십시오. 다음 스크린 샷은 GUI 로그인, 두 클러스터 노드 연결 및 Comm 경로 작성 프로세스를 안내합니다.

1 단계 : 1 차 서버에 연결 2 단계 : 2 차 서버에 연결 3 단계 : 통신 경로 생성 4 단계 : 로컬 및 원격 서버 선택 5 단계 : 장치 유형 선택 다음으로 일련의 대화 상자가 표시됩니다. 각 상자에 필요한 정보를 입력하고 다음을 클릭하여 진행하십시오. (대화 상자의 각 필드에 대한 추가 정보는 도움말을 클릭하십시오.) 6 단계 : 로컬 서버의 IP 주소를 Comm 경로에 사용하도록 선택하십시오. 7 단계 : 원격 서버의 IP 주소를 선택하여 Comm 경로에 사용하십시오. 8 단계 : Enter 로컬 서버의 통신 경로 우선 순위 모든 필수 필드에 데이터를 입력 한 후 만들기를 클릭합니다. 네트워크 통신 경로가 성공적으로 생성되었음을 나타내는 메시지가 표시됩니다. 9 단계 : 통신 경로 작성 완료 다음을 클릭하십시오. 여러 로컬 IP 주소 또는 원격 서버를 선택하고 장치 유형을 TCP로 설정하면 설치 마법사로 돌아가서 다음 Comm 경로를 만듭니다. 작업이 끝나면 마지막 대화 상자에서 완료를 클릭하십시오. 사용하려는 모든 Comm 경로를 정의 할 때까지이 프로세스를 반복하십시오. 서버 등록 정보 대화 상자를보고 통신 경로가 올바르게 구성되었는지 확인하십시오. GUI에서 편집> 서버> 등록 정보를 선택한 다음 CommPaths 탭을 선택합니다. 표시되는 상태는 ALIVE 여야합니다. GUI의 오른쪽 기본 분할 창에서 서버 아이콘을 점검 할 수도 있습니다. 하나의 Comm 경로 만 생성 된 경우 서버 아이콘이 노란색 경고 아이콘으로 오버레이됩니다. 녹색 하트 비트 체크 표시는 최소 두 개의 통신 경로가 구성되어 있고 살아 있는지 나타냅니다. 10 단계 : 통신 경로 상태 검토

IP 자원 생성 및 확장

LifeKeeper GUI에서 다음 단계를 완료하여 IP 자원을 작성하고이를 보조 서버로 확장하십시오. 이 가상 IP는 클러스터 노드에 종속 된 응용 프로그램과 함께 클러스터 노드간에 이동할 수 있습니다. 클러스터 구성의 일부로 가상 IP를 사용하면 동일한 FQDN / IP를 통해 데이터베이스에 계속 액세스하므로 클러스터 노드간에 자원을 전환하거나 장애 조치 할 때 클라이언트를 원활하게 리디렉션 할 수 있습니다. 11 단계 : 자원 계층 작성 12 단계 : IP ARK 선택 다음 권장 값을 사용하여 구성에 적합한 정보를 입력하십시오. 자세한 정보는 도움말 버튼을 클릭하십시오. 필수 정보를 입력 한 후에 계속하려면 다음을 클릭하십시오.

들	팁
자원 유형	자원 유형으로 IP 주소를 선택하고 다음을 누르십시오.
스위치 백 유형	지능형을 선택하고 다음을 클릭하십시오.
섬기는 사람	IP 자원을 작성할 서버를 선택하십시오. 주 서버를 선택하고 다음을 클릭하십시오.
IP 자원	가상 IP 정보를 입력하고 다음을 클릭하십시오 (이것은 네트워크상의 어느 곳에서도 사용되지 않는 IP 주소입니다. 모든 클라이언트는이 주소를 사용하여 보호 된 리소스에 연결합니다.)
넷 마스크	TCP / IP 자원이 목표 시스템에서 사용할 IP 서브 네트 마스크를 입력하십시오. 특정 TCP / IP 자원 주소 클래스의 모든 표준 넷 마스크가 유효합니다. IP 주소와 결합 된 서브넷 마스크는 TCP / IP 리소스가 사용할 서브넷을 결정하며 네트워크 구성과 일치해야합니다.이 샘플 구성 255.255.255.0은 두 네트워크의 서브넷 마스크에 사용됩니다.
네트워크 연결	IP 주소가 인터페이싱하는 실제 이더넷 카드를 입력합니다. 가상 IP 주소를 라우팅 할 수있는 네트워크 연결을 선택하십시오. 올바른 NIC를 선택하고 다음을 클릭하십시오.
IP 자원 태그	기본값을 채택하고 다음을 클릭하십시오. 이 값은 IP가 GUI에 표시되는 방법에만 영향을줍니다. IP 자원이 1 차 서 v에 작성됩니다.

LifeKeeper는 귀하의 리소스를 생성하고 검증합니다. 자원이 성공적으로 작성되었다는 메시지를 수신 한 후 다음을 클릭하십시오. 13 단계 : 성공적인 리소스 생성 알림 검토 이제 IP 리소스를 보조 서버로 확장하는 프로세스를 완료 할 수 있습니다. 14 단계 : IP 자원을 2 차 서버로 확장 IP 자원 확장을 완료하면 IP 자원 확장 프로세스가 자동으로 시작되고 다음을 클릭하십시오. 활성 자원을 마우스 오른쪽 단추로 누르고 자원 계층 구조 확장을 선택하여 기존 IP 주소 자원에서이 프로세스를 시작할 수도 있습니다. 다음 표의 정보를 사용하여 절차를 완료하십시오.

들	추천 항목 또는 메모
스위치 백 유형	지능형으로두고 다음을 클릭하십시오.
템플릿 우선 순위	기본값 (1)으로 두십시오.
목표 우선 순위	기본값 (10)으로 두십시오.
네트워크 인터페이스	이것은 IP 주소가 인터페이스하는 물리적 이더넷 카드입니다. 가상 IP 주소를 라우팅 할 수있는 네트워크 연결을 선택하십시오. 올바른 물리적 NIC를 기본적으로 선택해야합니다. 확인한 후 다음을 클릭하십시오.
IP 자원 태그	기본적으로 그대로 둡니다.
대상 복원 모드	사용을 선택하고 다음을 클릭하십시오.
대상 로컬 복구	대상 서버에서 SQL 자원에 대한 로컬 복구를 사용 가능하게하려면 예를 선택하십시오.
백업 우선 순위	기본값을 승인하십시오.

계층 구조 확장 작업이 완료되었다는 메시지를받은 후에 마침을 클릭 한 다음 완료를 클릭합니다. IP 리소스 (예 : 192.168.197.151)는 이제 완전히 보호되며 필요에 따라 클러스터 노드간에 플로팅 할 수 있습니다. LifeKeeper GUI에서 IP 자원이 기본 클러스터 노드에서 활성으로 표시되고 보조 클러스터 노드에서 대기로 표시됨을 알 수 있습니다. 15 단계 : 기본 및 보조 노드에서 IP 자원 상태 검토

미러 생성 및 데이터 복제 시작

중도에서 공유 스토리지가없는 2 노드 MySQL 클러스터 생성! 클러스터 노드간에 MySQL 데이터를 동기화하는 데 사용할 데이터 복제 리소스를 설정하고 구성 할 준비가되었습니다. 이 예제에서 복제 할 데이터는 기본 클러스터 노드의 / var / lib / mysql 파티션에 있습니다. 원본 볼륨은 주 서버에 탑재되어야하며 대상 볼륨은 보조 서버에 탑재되어서는 안되며 대상 볼륨 크기는 원본 볼륨 크기와 같거나 커야합니다. 다음 스크린 샷은 다음 단계를 설명합니다. 16 단계 : 자원 계층 작성 17 단계 : 데이터 복제 ARK 선택 데이터 복제 마법사에서이 값을 사용하십시오.

들	추천 항목 또는 메모
스위치 백 유형	지능형을 선택하십시오.
섬기는 사람	LinuxPrimary (기본 클러스터 노드 또는 미러 소스)를 선택하십시오.
계층 구조 유형	Replicate Existing Filesystem을 선택하십시오.
기존 마운트 포인트	복제 할 마운트 된 파티션을 선택하십시오. 이 예제에서 / var / lib / mysql.
데이터 복제 리소스 태그	기본적으로 그대로 둡니다.
파일 시스템 자원 태그	기본적으로 그대로 둡니다.
비트 맵 파일	기본적으로 그대로 둡니다.
비동기 복제 사용	기본값으로 두십시오 (예).

다음을 클릭하여 데이터 복제 자원 계층 구조 작성을 시작하십시오. GUI에 다음 메시지가 표시됩니다. 18 단계 : 데이터 복제 리소스 만들기 시작 데이터 복제 리소스 확장 프로세스를 시작하려면 다음을 클릭하십시오. 모든 기본 설정을 수락하십시오. 대상 디스크를 묻는 메시지가 표시되면이 프로세스의 앞부분에서 만든 대상 서버에서 사용 가능한 파티션을 선택하십시오. 소스 볼륨보다 크거나 큰 파티션이고 대상 시스템에 마운트되지 않은 파티션을 선택하십시오. 19 단계 : 데이터 복제 리소스 확장 시작 결국 복제를 수행 할 네트워크를 선택하라는 메시지가 나타납니다. 일반적으로 사용자 트래픽과 응용 프로그램 트래픽을 복제 트래픽과 분리하는 것이 좋습니다. 이 예제 구성에는 192.168.197.X 서브넷의 "공용 NIC"와 192.168.198.X 서브넷의 "개인 / 백엔드 NIC"의 두 가지 별도 네트워크 인터페이스가 있습니다. 우리는 백엔드 네트워크 192.168.198.X를 통과하도록 복제를 구성하여 사용자 및 응용 프로그램 트래픽이 복제와 경쟁하지 않도록합니다. 20 단계 : 복제 트래픽을위한 네트워크 선택 다음을 클릭하여 마법사를 계속 진행합니다. 완료되면 자원 계층 구조는 다음과 같습니다. 21 단계 : 데이터 복제 자원 계층 검토

MySQL 리소스 계층 구조 만들기

MySQL 데이터베이스를 보호하고 클러스터 노드간에 가용성을 높이려면 MySQL 리소스를 만들어야합니다. 이 시점에서 MySQL은 주 서버에서 실행 중이지만 보조 서버에서 실행 중이어야합니다. GUI 도구 모음에서 자원 계층 작성을 누르십시오. MySQL 데이터베이스를 선택하고 다음을 클릭하십시오. 다음 값을 제공하는 자원 생성 마법사를 계속 진행하십시오.

들	추천 항목 또는 메모
스위치 백 유형	지능형을 선택하십시오.
섬기는 사람	LinuxPrimary (기본 클러스터 노드)를 선택하십시오.
my.cnf의 위치	/ var / lib / mysql을 입력하십시오. (이전의 MySQL 구성 과정에서이 디렉토리에 my.cnf 파일을 만들었습니다.)
MySQL 실행 파일의 위치	이 예제에서는 표준 MySQL 설치 / 구성을 사용하기 때문에 기본값 (/ usr / bin)으로 두십시오.
데이터베이스 태그	기본적으로 그대로 둡니다.

기본 서버에서 MySQL 자원 계층을 정의하려면 Create를 클릭하십시오. 다음을 클릭하여 파일 시스템 리소스를 보조 서버로 확장합니다. 확장 마법사에서 기본값 수락을 선택하십시오. 마침을 클릭하여 확장 마법사를 종료하십시오. 리소스 계층 구조는 다음과 같아야합니다. 22 단계 : MySQL 자원 계층 검토

MySQL IP 주소 의존성 만들기

다음으로 가상 IP (192.168.197.151)에 의존하도록 MySQL을 구성하여 이동하는 IP 주소가 MySQL 데이터베이스를 따르도록합니다. GUI 도구 모음에서 mysql 자원을 마우스 오른쪽 단추로 누르십시오. 컨텍스트 메뉴에서 종속성 작성을 선택하십시오. 하위 리소스 태그 드롭 다운 메뉴에서 ip-192.168.197.151을 선택하십시오. 다음을 클릭하고 종속성 만들기를 클릭 한 다음 완료를 클릭합니다. 리소스 계층은 이제 다음과 같이 보일 것입니다. 23 단계 : MySQL IP 리소스 계층 구조 평가 이제 평가에서는 MySQL 및 종속 리소스 (IP 주소 및 복제 된 저장소)를 완전히 보호했습니다. 환경을 테스트하면 바로 사용할 수 있습니다. 데이터 복제 평가 가이드가 포함 된 Linux 용 MySQL MySQL 용 SIOS SteelEye Protection Suite에서 평가 프로세스의 모든 단계에 대한 자세한 정보와 세부 단계를 확인할 수 있습니다. Linux 용 SPS 평가판을 다운로드하려면 SIOS 웹 사이트를 방문하거나 SIOS (info@us.sios.com)에 문의하십시오. 공유 스토리지가없는 2- 노드 MySQL 클러스터를 만드는 방법을 배우고 자하는 고객 만족의 과거 사례를 살펴보십시오. Linux 클러스터링의 허락을 받아 재현