자료실

공유 스토리지가없는 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 클러스터링의 허락을 받아 재현

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

11월 29, 2018 by Jason Aw Leave a Comment

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

MySQL 클러스터를 실행하는 주된 이점은 분명히 고 가용성 (HA)입니다. 이러한 유형의 솔루션을 최대한 활용하려면 잠재적 단일 실패 지점을 가능한 많이 제거해야합니다. 기존의 통념에 따르면 클러스터링 아키텍처에서 기술적으로 단일 실패 지점을 나타내는 일부 유형의 공유 저장소가 없으면 클러스터를 구성 할 수 없다고합니다. 그러나 해결책이 있습니다. Linux 용 SteelEye Protection Suite (SPS)를 사용하면 클러스터 노드간에 실시간 데이터 복제를 제공하여 스토리지를 단일 실패 지점으로 제거 할 수 있습니다. 일반적인 시나리오를 살펴 보겠습니다. 로컬 복제 된 스토리지를 활용하여 MySQL 데이터베이스를 보호하는 클러스터를 구성합니다.

Shared Storage를 사용하지 않고 2 노드 MySQL 클러스터를 생성하려면 실험 환경에서 SPS 평가판으로 작업하고 있다고 가정합니다. 또한 주 서버와 보조 서버 및 네트워크가 모두 이러한 유형의 설치를 실행하기위한 요구 사항을 충족하는지 확인했다고 가정합니다. (이러한 요구 사항에 대한 자세한 내용은 Linux 용 SIOS SteelEye Protection Suite 데이터 복제 평가 가이드를 참조하십시오.)

공유 스토리지가없는 2 노드 MySQL 클러스터를 만들기위한 첫 번째 단계

클러스터 설정을 시작하기 전에 스토리지를 구성해야합니다. 복제하려는 데이터는 별도의 파일 시스템이나 논리 볼륨에 있어야합니다. 파티션이나 논리적 볼륨을 사용하는 대상 디스크의 크기는 소스와 같거나 커야합니다. 이 예에서는 디스크 파티션을 사용하고 있다고 가정합니다. (그러나 LVM도 완벽하게 지원됩니다.) 먼저 SteelEye DataKeeper와 함께 사용할 수 있도록 로컬 스토리지를 파티션하십시오. 주 서버에서 MySQL 저장소로 사용하거나 사용하지 않는 디스크 파티션을 확인하거나 새 파티션을 만듭니다. fdisk 유틸리티를 사용하여 디스크를 파티션 한 다음 파티션을 포맷하고 일시적으로 / mnt에 마운트하십시오. / var / lib / mysql /에있는 기존 데이터를이 새 디스크 파티션으로 옮깁니다 (기본 MySQL 구성으로 가정). / var / lib / mysql에서 파티션을 마운트 해제했다가 다시 마운트하십시오. SPS에 의해 자동으로 마운트되기 때문에이 파티션을 / etc / fstab에 추가 할 필요가 없습니다. 보조 서버에서 기본 서버에서 수행 한 것처럼 디스크를 구성하십시오.

MSQL 설치

다음으로 MySQL을 다룰 것입니다. 기본 서버에서 mysql 및 mysql-server RPM 패키지를 모두 설치하고 (시스템에 아직없는 경우) 필요한 종속성을 적용합니다. 로컬 디스크 파티션이 / var / lib / mysql에 마운트되어 있는지 확인하십시오. 필요한 경우 샘플 MySQL 데이터베이스를 초기화하십시오. MySQL 데이터 디렉토리 (/ var / lib / mysql)의 모든 파일이 올바른 사용 권한과 소유권을 가지고 있는지 확인한 다음 명령 줄에서 수동으로 MySQL 데몬을 시작하십시오. (참고 : service 명령이나 /etc/init.d/ 스크립트를 통해 MySQL을 시작하지 마십시오.) mysql 클라이언트와 연결하여 MySQL이 실행 중인지 확인하십시오. MySQL 구성의 루트 암호를 업데이트하고 확인하십시오. 그런 다음 여기에 표시된 샘플 파일과 같은 MySQL 구성 파일을 작성하십시오. —- # cat /var/lib/mysql/my.cnf [mysqld] datadir = / var / lib / mysql socket = / var / lib / mysql / mysql / mysql / mysqld.pid user = root port = 3306 # mysql 3.x # 클라이언트 (mysqlclient10 호환성 패키지를 사용하는 클라이언트)와의 호환성을 위해 이전 암호 형식을 사용하도록 디폴트 설정. old_passwords = 1 # 다양한 보안 위험을 방지하려면 심볼릭 링크를 비활성화하는 것이 좋습니다. # 심볼릭 링크 = 0 [mysqld_safe] log-error = / var / log / mysqld.log pid-file = / var / run / mysqld / mysqld.pid [클라이언트] user = root password = SteelEye —-이 예제에서 우리는이 파일을 나중에 복제 할 디렉토리 (/var/lib/mysql/my.cnf)에 저장합니다. 원본 MySQL 구성 파일을 삭제합니다 (/ etc). 보조 서버에서 필요한 경우 mysql 및 mysql-server RPM 패키지를 설치하고 종속성을 적용하고 MySQL 데이터 디렉토리 (/ var / lib / mysql)의 모든 파일에 올바른 사용 권한과 소유권이 있는지 확인하십시오.

Linux 용 SPS 설치

그런 다음 Linux 용 SPS를 설치하십시오. 설치 편의성을 위해 SIOS는 Linux 용 SPS 용 통합 설치 스크립트 ( "설치"라고 함)를 제공합니다. 이 소프트웨어를 구하는 방법에 대한 지침은 Linux 용 SPS 평가 라이센스 키와 함께 제공되는 전자 메일에 나와 있습니다. 기본 및 보조 서버 모두에서 소프트웨어 및 평가 라이센스 키를 다운로드하십시오. 각 서버에서 설치 스크립트를 실행하면 필요한 RPM, 코어 클러스터링 소프트웨어 및 필요한 모든 선택적 ARK가 설치됩니다. 이 경우 MySQL ARK (steeleye-lkSQL) 및 DataKeeper (Data Replication) ARK (steeleye-lkDR)를 설치해야합니다. / opt / LifeKeeper / bin / lkkeyins 명령을 통해 라이센스 키를 적용하고 시작 스크립트 인 / opt / LifeKeeper / lkstart를 통해 Linux 용 SPS를 시작하십시오. 이 시점에서 두 노드 모두에서 SPS가 설치, 라이센스 및 실행되고 보호하려는 디스크와 MySQL 데이터베이스가 구성됩니다. 다음 글에서는 비공유 클러스터링 프로세스의 나머지 단계를 살펴 보겠습니다. 다음을 작성하십시오.

기본 서버와 대상 서버 사이의 통신 (Comm) 경로, 즉 하트 비트
IP 자원
미러 및 시작 데이터 복제
MySQL 데이터베이스 리소스
MySQL IP 주소 의존성

프로젝트를 위해 공유 스토리지가없는 2-Node MySQL 클러스터를 생성하는 방법을 알고 싶거나 우리와 채팅하거나 성공 사례를 읽으십시오. Linux 클러스터링의 허락을 받아 재현

VMware 고 가용성을 통한 장애 조치 (Failover) 클러스터링이 완벽하게 일치합니까?

11월 28, 2018 by Jason Aw Leave a Comment

VMware 고 가용성을 통한 장애 조치 (Failover) 클러스터링 : 잔인하거나 완벽하게 일치합니까?

VMware 계층에서 고 가용성 (HA)을 구현하는 것이 유용한 솔루션입니다. 그것은 어떤 유형의 실패로부터 보호하는 데 도움이됩니다. 그러나 VMware HA만으로는 모든 기반을 포괄하지 못합니다. VMware 고 가용성을 통한 페일 오버 클러스터링의 가능성에 대해 알아 보겠습니다.

Gartner Research에 따르면 대부분의 계획되지 않은 중단은 응용 프로그램 오류 (중단의 40 %) 또는 관리자 오류 (40 %)로 인해 발생합니다. 하드웨어, 네트워크, 전원 또는 환경 문제로 나머지는 20 %가됩니다. VMware HA는 하드웨어 오류에 대한 보호에 중점을 두지 만 다른 응용 프로그램 클러스터링 솔루션은 다른 영역에서 느슨해집니다.

VMware High Availability를 통한 장애 조치 (Failover) 클러스터링을 위해서는 훌륭한 전략이 필요합니다.

다음은 VMware 환경에 적합한 HA 전략을 수립 할 때 고려해야 할 몇 가지 사항입니다.

응용 프로그램 수준 모니터링 및 클러스터링으로 중단 시간 단축

복구 속도는 어떻습니까? 완벽한 세계에서는 실패, 정전 또는 가동 중지 시간이 없습니다. 그러나 계획되지 않은 정전이 발생하면 가장 좋은 방법은 다시 일어나서 다시 빨리 움직이는 것입니다. 이 방정식은 환경의 총 가용성을 나타냅니다. 알 수 있듯이 감지 시간은 방정식의 중요한 부분입니다. 여기에 VMware HA만으로는 잘리지 않는 곳이 있습니다. VMware HA는 각 가상 시스템 (VM)을 "블랙 박스 (black box)"로 취급하며 내부에서 실행되는 응용 프로그램의 상태 또는 상태를 실제로 볼 수 없습니다. 내부에서 실행중인 VM 및 OS는 문제가 없지만 응용 프로그램이 중지되거나 중단되거나 잘못 구성된 경우 사용자가 중단 될 수 있습니다. 호스트 서버 장애가 문제가 되더라도 VMware HA가 VMware 클러스터의 다른 호스트에서 영향을받는 VM을 다시 시작하기를 기다려야합니다. 즉, 해당 VM에서 실행중인 응용 프로그램은 1) 작동 중단이 감지되고, 2) OS가 새 호스트 시스템에서 완전히 부팅되고, 3) 응용 프로그램이 다시 시작되고 4) 사용자가 응용 프로그램에 다시 연결할 때까지 중단됩니다. 여러 VM 사이의 응용 프로그램 계층에서 클러스터링하면 응용 프로그램 수준의 중단으로부터 보호받을 수있을뿐만 아니라 중단 복구 시간도 단축 할 수 있습니다. 응용 프로그램은 이미 부팅되고 인계 받기를 기다리는 대기 VM에서 다시 시작될 수 있습니다. 가용성을 최대화하려면 관련된 VM이 서로 다른 물리적 서버에 있어야합니다. 또는 더 나은, 별도의 VMware HA 클러스터 또는 별도의 데이터 센터!

잠재적 인 단일 장애 지점 (SPOF)으로 스토리지 제거

VMware HA를 비롯한 기존의 클러스터링 솔루션은 공유 스토리지를 요구하며 일반적으로 단일 데이터 센터 내에서만 애플리케이션 또는 서비스를 보호합니다. 기술적으로 공유 저장 장치는 아키텍처에서 SPOF를 나타냅니다. 백엔드 스토리지에 대한 액세스 권한을 잃어 버리면 클러스터와 응용 프로그램이 중단됩니다. 모든 HA 솔루션의 목표는 가능한 많은 SPOF를 제거하여 전반적인 가용성을 향상시키는 것입니다. 그렇다면 더 높은 수준의 가용성을 제공하기 위해 기본 VMware HA 클러스터를 어떻게 강화할 수 있습니까? 하드웨어에서 애플리케이션으로 전체 스택을 보호하려면 VMware HA부터 시작하십시오. 그런 다음 응용 프로그램을 모니터하고 보호하는 방법이 필요합니다. 애플리케이션 레벨 (즉, VM 내)에서의 클러스터링은 당연한 선택이다. 호스트 기반 데이터 복제 (즉, 비공유 구성)를 지원하는 클러스터링 솔루션을 선택해야 SAN 기반 복제 설정 비용 및 복잡성을 겪지 않아도됩니다. 또한 SAN 복제 솔루션은 일반적으로 단일 저장소 공급 업체로 사용자를 제한합니다. 또한 공유 저장소를 사용하여 VM을 클러스터링하려면 일반적으로 Raw Device Mapping (RDM)을 사용하도록 설정해야합니다. 즉, vMotion과 같은 많은 강력한 VMware 기능에 액세스하지 못하게됩니다. 비공유 클러스터 구성으로 이동하면 스토리지 계층이 SPOF로 제거됩니다. 동시에 vMotion을 사용하여 물리적 호스트간에 VM을 마이그레이션 할 수 있습니다. 윈 – 윈! 비공유 클러스터는 다른 데이터 센터에 상주 할 수 있으므로 재해 복구를위한 탁월한 솔루션입니다.

커버 모든 기지

VMware HA에 계층화 된 응용 프로그램 장애 조치 클러스터링은 두 가지 장점을 모두 제공합니다. 내장 된 하드웨어 보호 및 애플리케이션 인식, 뛰어난 유연성 및 확장 성, 빠른 복구 시간을 누릴 수 있습니다. 더 좋은 점은 솔루션이 은행을 해산 할 필요가 없다는 것입니다. VMware 고 가용성을 이용한 장애 조치 (failover) 클러스터링이 프로젝트에서 어떻게 작동하는지 이해하고 싶으십니까? SIOS로 체크인하십시오. LinuxClustering의 허가를 받아 재현

Fusion-io를 사용하여 Linux 클러스터링의 복제 성능 극대화

11월 27, 2018 by Jason Aw Leave a Comment

Linux 클러스터링에서 복제 성능을 극대화하는 팁 Fusion-io

대부분의 사람들은 클러스터 설정에 대해 생각할 때 대개 둘 이상의 서버와 SAN 또는 다른 유형의 공유 저장 장치를 필요로합니다. SAN은 일반적으로 설정 및 유지 관리에 매우 비용이 많이 들고 복잡합니다. 또한 클러스터 아키텍처에서 기술적으로 단일 장애 지점 (SPOF)을 나타냅니다. 요즘 점점 더 많은 사람들이 번개 빠른 ioDrive를 통해 Fusion-io와 같은 회사로 전환하여 중요한 응용 프로그램을 가속화하고 있습니다. 이러한 저장 장치는 서버 내에 있습니다 (즉, "공유 디스크"가 아닙니다). 따라서 기존의 많은 클러스터링 솔루션이있는 클러스터 디스크로 사용할 수 없습니다. 다행스럽게도 Fusion-io를 사용하여 Linux 클러스터링의 복제 성능을 극대화하는 방법이 있습니다. 공유 저장 장치가없는 경우 장애 조치 클러스터를 구성 할 수있는 솔루션, 즉 "공유되지 않은"클러스터.


전통적 클러스터	"Shared Nothing"클러스터

클러스터 구성의 일부로 데이터 복제를 활용할 때는 충분한 대역폭을 확보하여 디스크에 기록 된 것만큼 빠르게 네트워크를 통해 데이터를 복제 할 수 있어야합니다. 다음은 고속 스토리지가 관련되어있을 때 "공유 안 함"클러스터 구성을 최대한 활용할 수있게 해주는 튜닝 팁입니다.

회로망

10Gbps NIC 사용 : Fusion-io의 플래시 기반 저장 장치 (또는 OCZ, LSI 등의 유사한 제품)는 HUNDREDS (750) MB / 초 이상의 속도로 데이터를 쓸 수 있습니다. 1Gbps NIC는 이론상 최대 ~ 125MB / sec의 속도를 낼 수 있기 때문에 ioDrive의 잠재력을 이용하는 모든 사람이 1Gbps 네트워크 연결을 통해 전달할 수있는 것보다 훨씬 빨리 데이터를 쓸 수 있습니다. 실시간 데이터 복제를 용이하게하기 위해 서버간에 충분한 대역폭을 확보하려면 복제 트래픽을 전달하는 데 항상 10Gbps NIC를 사용해야합니다
점보 프레임 활성화 : 네트워크 카드와 스위치가이를 지원한다고 가정하면 점보 프레임을 활성화하면 네트워크 처리량을 크게 늘릴 수 있으며 동시에 CPU주기를 줄일 수 있습니다. 점보 프레임을 활성화하려면 다음 구성을 수행하십시오 (예 : RedHat / CentOS / OEL Linux 서버)
- ifconfig <인터페이스 이름> mtu 9000
- / etc / sysconfig / network-scripts / ifcfg- <interface_name> 파일을 편집하고 "MTU = 9000"을 추가하여 재부팅시 변경 사항이 지속되도록하십시오
- 엔드 – 투 – 엔드 점보 프레임 작동을 확인하려면 다음 명령을 실행하십시오. ping -s 8900 -M do <IP-of-other-server>
NIC의 전송 대기열 길이 변경 :
- / sbin / ifconfig <인터페이스 _ 이름> txqueuelen 10000
- 다시 부팅 할 때마다 설정을 유지하려면 /etc/rc.local에 추가하십시오.

TCP / IP 조정

NIC의 netdev_max_backlog를 변경하십시오.
- /etc/sysctl.conf에 "net.core.netdev_max_backlog = 100000"을 설정하십시오.
복제 성능을 향상시키는 다른 TCP / IP 조정 :
- 참고 :이 값은 예제 값이며 하드웨어 구성에 따라 조정해야 할 수도 있습니다
- /etc/sysctl.conf를 편집하고 다음 매개 변수를 추가하십시오.
  - net.core.rmem_default = 16777216
  - net.core.wmem_default = 16777216
  - net.core.rmem_max = 16777216
  - net.core.wmem_max = 16777216
  - net.ipv4.tcp_rmem = 4096 87380 16777216
  - net.ipv4.tcp_wmem = 4096 65536 16777216
  - net.ipv4.tcp_timestamps = 0
  - net.ipv4.tcp_sack = 0
  - net.core.optmem_max = 16777216
  - net.ipv4.tcp_congestion_control = htcp

조정

일반적으로 구현하려는 클러스터링 및 복제 기술에 따라 달라지는 클러스터 구성을 조정해야합니다. 이 예에서는 SIOS Technologies의 Linux 용 SteelEye Protection Suite (일명 LifeKeeper SPS)를 사용하고 있습니다. 사용자는 파이버 채널 SAN, iSCSI, NAS 또는이 기사와 가장 관련이있는 클러스터 노드간에 실시간으로 동기화 / 복제해야하는 로컬 디스크를 비롯하여 모든 백 엔드 저장소 유형을 활용하여 장애 조치 (failover) 클러스터를 구성 할 수 있습니다. SPS for Linux에는 통합 된 블록 레벨 데이터 복제 기능이 포함되어있어 공유 스토리지가 필요없는 클러스터를 쉽게 설정할 수 있습니다.

권장 사항

Fusion-io를 사용하여 Linux 클러스터링의 복제 성능을 극대화하려면 다음을 시도해보십시오. Linux 구성 권장 사항 인 SteelEye Protection Suite (SPS) :

Fusion-io 드라이브에있는 작은 (~ 100 MB) 디스크 파티션을 할당하여 비트 맵 파일을 배치하십시오. 이 파티션에 파일 시스템을 만들고 마운트합니다 (예 : / bitmap).
- # mount | grep / bitmap
- / dev / fioa1 on / 비트 맵 유형 ext3 (rw)
미러를 만들기 전에 / etc / default / LifeKeeper에서 다음 매개 변수를 조정하십시오
- 삽입 : LKDR_CHUNK_SIZE = 4096
  - 기본값은 64입니다.
- 편집 : LKDR_SPEED_LIMIT = 1500000
  - (기본값은 50000 임)
  - LKDR_SPEED_LIMIT는 재 동기화가 취할 최대 대역폭을 지정합니다.이 값은 가능한 한 최대 속도로 재 동기화를 수행 할 수 있도록 충분히 높게 설정해야합니다
- 편집 : LKDR_SPEED_LIMIT_MIN = 200000
  - (기본값은 20000 임)
  - LKDR_SPEED_LIMIT_MIN은 다른 I / O가 동시에 진행될 때 재 동기화를 허용하는 속도를 지정합니다. 일반적으로 굶주림을 피하려면 드라이브의 최대 쓰기 처리량의 절반 이하로 설정해야합니다 재 동기화가 발생할 때 정상 I / O 활동을 종료합니다.

여기에서 계속해서 거울을 만들고 평소와 같이 클러스터를 구성하십시오. Linux 클러스터링에서 복제 성능 극대화에 관심 Fusion-io를 사용하면 SIOS가 제공 할 수있는 다른 기능을 살펴보십시오. LinuxClustering의 허가를 받아 재현

Google 도메인 간 Google 양식 이동

11월 23, 2018 by Jason Aw Leave a Comment

Google 도메인 간 Google 양식 이동

나 같은 사람이라면 정기적으로 함께 일하는 몇 가지 다른 Google 계정이있을 것입니다. 최근 Google 도메인 간 Google 양식 이동에 도움이 필요했습니다. Google 양식을 만들 때 상당한 시간을 보냈습니다. 오직 내 직장 계좌가 아닌 개인 계좌로 로그인 한 상태에서이 작업을 수행했다는 것을 깨닫기 만하면됩니다. 나는 그 일을 다시하고 싶지 않았습니다. 온라인으로 답변을 검색했지만 특정 상황이 해결되지 않았습니다. 그것은하기가 어렵지 않습니다. 나는 그것이 당신에게 일어날 경우에 대비하여 적어 놓을 것이라고 생각했습니다. 나는 몇 가지 시도 만해서 문제를 발견했다. 이것이 데이터가없는 새로운 형식이라고 가정 해 봅시다. Google 도메인 간 Google 양식 이동에서 수행해야하는 작업은 다음과 같습니다.

두 번째 Google 계정을 양식의 공동 작업자로 추가하십시오.
두 번째 Google 계정에 로그인하고 양식을 열고 양식 사본을 만듭니다.

Google 도메인 간 Google 양식 이동 그게 다야! 이제 두 번째 Google 계정에 양식 사본이 있습니다. 물론 첫 번째 양식에서 일부 데이터를 수집 한 경우 해당 시트를 복사해야합니다. 두 번째 Google 계정에도 넣고 양식을 데이터 사본에 첨부하십시오. 실수로 이전 양식을 사용하지 않도록 이전 양식을 삭제하십시오. Google 도메인간에 Google 양식 이동하기와 같은 도움말을 읽어보십시오. Clusteringformeremortals의 허가를 받아 복제했습니다.