SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

8월 18, 2020

단계별 : Amazon EC2에서 SANless MySQL Linux 장애 조치 클러스터를 구성하는 방법

단계별 : Amazon EC2에서 SANless MySQL Linux 장애 조치 클러스터를 구성하는 방법

단계별 : Amazon EC2에서 SANless MySQL Linux 장애 조치 클러스터를 구성하는 방법

이 단계별 가이드에서는 Amazon의 Elastic Compute Cloud (Amazon EC2)에서 고 가용성 2 노드 MySQL 클러스터 (감시 서버 포함)를 구성하는 데 필요한 모든 단계를 안내합니다. 가이드에는 스크린 샷, 셸 명령 및 코드 조각이 모두 포함되어 있습니다. Amazon EC2에 어느 정도 익숙하고 이미 계정이 있다고 가정합니다. 그렇지 않은 경우 오늘 가입 할 수 있습니다. 또한 Linux 시스템 관리 및 가상 IP 등과 같은 장애 조치 클러스터링 개념에 대한 기본적인 지식이 있다고 가정하겠습니다.

장애 조치 클러스터링은 수년 동안 사용되어 왔습니다. 일반적인 구성에서는 두 개 이상의 노드가 공유 스토리지로 구성되어 기본 노드에서 장애 조치가 발생할 경우 보조 또는 대상 노드가 최신 데이터에 액세스 할 수 있습니다. 공유 스토리지를 사용하면 거의 0에 가까운 복구 지점 목표가 가능할뿐만 아니라 대부분의 클러스터링 소프트웨어에 대한 필수 요구 사항입니다. 그러나 공유 스토리지에는 몇 가지 문제가 있습니다. 첫째, 단일 장애 지점 위험입니다. 공유 스토리지 (일반적으로 SAN)가 실패하면 클러스터의 모든 노드가 실패합니다. 둘째, SAN은 비용이 많이 들고 구매, 설정 및 관리가 복잡 할 수 있습니다. 셋째, Amazon EC2를 포함한 퍼블릭 클라우드의 공유 스토리지는 고 가용성 (99.99 % 가동 시간), 거의 제로에 가까운 복구 시간 및 복구 지점 목표, 재해 복구 보호를 유지하려는 회사에게는 불가능하거나 실용적이지 않습니다.

다음은 엄격한 HA / DR SLA를 충족하면서 이러한 문제를 제거하기 위해 클라우드에서 SANless 클러스터를 생성하는 것이 얼마나 쉬운 지 보여줍니다. 아래 단계에서는 Amazon EC2와 함께 MySQL 데이터베이스를 사용하지만 SQL, SAP, Oracle 또는 기타 애플리케이션을 보호하기 위해 AWS에서 2 노드 클러스터를 생성하는 데 동일한 단계를 적용 할 수 있습니다.

참고 : 기능, 화면 및 버튼보기는 아래에 제시된 스크린 샷과 약간 다를 수 있습니다.

1. Virtual Private Cloud (VPC) 생성
2. 인터넷 게이트웨이 생성
삼. 서브넷 생성 (가용 영역)
4. 라우팅 테이블 구성
5. 보안 그룹 구성
6. 인스턴스 시작
7. 탄력적 IP 생성
8. 가상 IP에 대한 경로 항목 생성
9. ENI에 대한 소스 / 대상 확인 비활성화
10. 액세스 키 ID 및 보안 액세스 키 얻기
11. Linux OS 구성
12. EC2 API 도구 설치
13. MySQL 설치 및 구성
14. 클러스터 설치 및 구성
15. 클러스터 연결 테스트

개요

이 문서에서는 단일 Amazon EC2 리전 내에서 클러스터를 생성하는 방법을 설명합니다. 클러스터 노드 (node1, node2 및 감시 서버)는 최대 가용성을 위해 서로 다른 가용성 영역에 상주합니다. 이는 또한 노드가 다른 서브넷에 있음을 의미합니다.

다음 IP 주소가 사용됩니다.

  • node1 : 10.0.0.4
  • node2 : 10.0.1.4
  • 증인 : 10.0.2.4
  • 가상 / "부동"IP : 10.1.0.10

1 단계 : Virtual Private Cloud (VPC) 생성

먼저 Virtual Private Cloud (VPC라고도 함)를 만듭니다. VPC는 전용 Amazon 클라우드 내의 격리 된 네트워크입니다. IP 주소 블록 및 서브넷, 라우팅 테이블, 보안 그룹 (예 : 방화벽) 등을 완벽하게 제어 할 수 있습니다. 가상 네트워크에 Azure Iaas VM (가상 머신)을 시작합니다.

기본 AWS 대시 보드에서 "VPC"를 선택합니다.

"Your VPCs"아래에서 화면 오른쪽 상단에서 적절한 지역을 선택했는지 확인합니다. 이 가이드에서는 3 개의 가용 영역이있는 리전이므로 "미국 서부 (오레곤)"리전이 사용됩니다. 지역 및 가용 영역에 대한 자세한 내용을 보려면 여기를 클릭하세요.

VPC에 이름을 지정하고 사용할 IP 블록을 지정합니다. 이 가이드에서는 10.0.0.0/16이 사용됩니다.

이제“Your VPCs”화면에 새로 생성 된 VPC가 표시됩니다.

2 단계 : 인터넷 게이트웨이 생성

다음으로 인터넷 게이트웨이를 만듭니다. 인스턴스 (VM)가 인터넷과 통신 할 수 있도록하려는 경우 필요합니다.

왼쪽 메뉴에서 인터넷 게이트웨이를 선택하고 인터넷 게이트웨이 만들기 버튼을 클릭합니다. 이름을 지정하고 다음을 만듭니다.

다음으로 인터넷 게이트웨이를 VPC에 연결합니다.

VPC를 선택하고 연결을 클릭합니다.

 

3 단계 : 서브넷 생성 (가용 영역)

다음으로 서브넷 3 개를 만듭니다. 각 서브넷은 자체 가용 영역에 상주합니다. 3 개의 인스턴스 (VM : node1, node2, 감시)는 별도의 서브넷 (따라서 가용 영역)으로 시작되므로 가용 영역의 장애로 인해 클러스터의 여러 노드가 제거되지 않습니다.

미국 서부 (오레곤) 리전 인 us-west-2에는 3 개의 가용성 영역 (us-west-2a, us-west-2b, us-west-2c)이 있습니다. 3 개의 가용성 영역 각각에 하나씩 3 개의 서브넷을 만듭니다.

VPC 대시 보드에서 서브넷으로 이동 한 다음 서브넷 생성 :

첫 번째 서브넷에 이름 (“Subnet1)”을 지정하고 가용성 영역 us-west-2a를 선택한 다음 네트워크 블록 (10.0.0.0/24)을 정의합니다.

두 번째 서브넷 가용성 영역 us-west-2b를 생성하려면 반복합니다.

us-west-2c 가용성 영역에 세 번째 서브넷을 생성하려면 반복합니다.

완료되면 아래에 표시된대로 각각 다른 CIDR 블록과 별도의 가용 영역에 3 개의 서브넷이 생성되었는지 확인합니다.

4 단계 : 라우팅 테이블 구성

외부로의 트래픽이 이전 단계에서 만든 인터넷 게이트웨이로 전송되도록 VPC의 라우팅 테이블을 업데이트합니다. VPC 대시 보드에서 라우팅 테이블을 선택합니다. Routes 탭으로 이동하면 기본적으로 VPC 내에서만 트래픽을 허용하는 하나의 경로 만 존재합니다.

편집을 클릭하십시오.

다른 경로 추가 :

새 경로의 대상은 "0.0.0.0/0"(인터넷)이고 대상에 대해 인터넷 게이트웨이를 선택합니다. 그런 다음 저장을 클릭합니다.

다음으로 3 개의 서브넷을 라우팅 테이블과 연결합니다. "서브넷 연결"탭을 클릭하고 편집 :

3 개의 서브넷 모두 옆에있는 확인란을 선택하고 저장합니다.

3 개의 서브넷이 기본 라우팅 테이블과 연결되어 있는지 확인합니다.

나중에 돌아와서 라우팅 테이블을 다시 한 번 업데이트하여 트래픽이 클러스터의 가상 IP와 통신 할 수 있도록 라우트를 정의 할 것입니다.하지만 이는 Linux 인스턴스 (VM)가 생성 된 후에 수행되어야합니다.

5 단계 : 보안 그룹 구성

들어오는 SSH 및 VNC 트래픽을 허용하도록 보안 그룹 (가상 방화벽)을 수정합니다. 둘 다 나중에 Linux 인스턴스를 구성하고 클러스터 소프트웨어의 설치 / 구성을 구성하는 데 사용됩니다.

왼쪽 메뉴에서 "보안 그룹"을 선택한 다음 "인바운드 규칙"탭을 클릭합니다. 편집을 클릭하십시오.

SSH (포트 22) 및 VNC 모두에 대한 규칙을 추가합니다. VNC는 일반적으로 구성 방법에 따라 5900의 포트를 사용하므로이 가이드의 목적에 따라 5900-5910 포트 범위를 엽니 다. VNC 설정에 따라 구성하십시오.

6 단계 : 인스턴스 시작

이 가이드에서는 3 개의 인스턴스 (가상 머신)를 프로비저닝합니다. 처음 두 개의 VM ( "node1"및 "node2"라고 함)은 MySQL 데이터베이스 및 관련 리소스를 온라인 상태로 만드는 기능을 가진 클러스터 노드로 작동합니다. 세 번째 VM은 분할 브레인에 대한 추가 보호를 위해 클러스터의 증인 서버 역할을합니다.

최대한의 가용성을 보장하기 위해 VM 3 개 모두 단일 지역 내의 서로 다른 가용성 영역에 배포됩니다. 이는 각 인스턴스가 다른 서브넷에 있음을 의미합니다.

기본 AWS 대시 보드로 이동하여 EC2를 선택합니다.

 

"node1"만들기

첫 번째 인스턴스 ( "node1")를 만듭니다. 인스턴스 시작을 클릭합니다.

Linux 배포를 선택하십시오. 나중에 사용되는 클러스터 소프트웨어는 RHEL, SLES, CentOS, Oracle Linux를 지원합니다. 이 가이드에서는 RHEL 7.X를 사용합니다.

그에 따라 인스턴스 크기를 조정하십시오. 이 가이드의 목적과 비용을 최소화하기 위해 t2.micro 크기가 사용되었습니다. 무료 등급이 적용되기 때문입니다. 인스턴스 크기 및 가격에 대한 자세한 내용은 여기를 참조하세요.

다음으로 인스턴스 세부 정보를 구성합니다. 중요 :이 첫 번째 인스턴스 (VM)를 "Subnet1"로 시작하고 서브넷 (10.0.0.0/24)에 유효한 IP 주소를 정의해야합니다. 서브넷의 첫 번째 사용 가능한 IP이므로 10.0.0.4 미만이 선택되었습니다.
참고 : AWS의 특정 서브넷에있는 .1 / .2 / .3은 예약되어 사용할 수 없습니다.

다음으로 클러스터 노드에 추가 디스크를 추가합니다 ( "node1"및 "node2"모두에서 수행됨). 이 디스크는 MySQL 데이터베이스를 저장하고 나중에 노드간에 복제됩니다.

참고 : '증인'노드에 디스크를 추가 할 필요가 없습니다. "node1"및 "node2"만. 새 볼륨을 추가하고 원하는 크기를 입력합니다.

인스턴스 Node1에 대한 태그를 정의하십시오.

인스턴스를 기존 보안 그룹과 연결하여 이전에 생성 한 방화벽 규칙이 활성화되도록합니다.

시작을 클릭합니다.

중요 : AWS 환경의 첫 번째 인스턴스 인 경우 새 키 쌍을 만들어야합니다. 비공개 키 파일은 Linux 인스턴스에 SSH로 연결할 때 필요하므로 안전한 위치에 저장해야합니다.

"node2"만들기

위의 단계를 반복하여 두 번째 Linux 인스턴스 (node2)를 만듭니다. Node1과 똑같이 구성하십시오. 하지만 'Subnet2'(us-west-2b 가용성 영역)에 배포해야합니다. Subnet2의 IP 범위는 10.0.1.0/24이므로 여기에서는 IP 10.0.1.4가 사용됩니다.

두 번째 디스크도 Node2에 추가해야합니다. Node1에 추가 한 디스크와 정확히 같은 크기 여야합니다.

두 번째 인스턴스에 태그 지정…. “Node2”:

"증인"만들기

위의 단계를 반복하여 세 번째 Linux 인스턴스 (증인)를 만듭니다. 두 번째 디스크를 추가 할 필요가 없다는 점을 제외하면 Node1 & Node2와 똑같이 구성합니다.이 인스턴스는 클러스터에 대한 감시 역할 만하며 MySQL을 온라인 상태로 만들지 않기 때문입니다.

'Subnet3'(us-west-2c 가용성 영역)에 배포해야합니다. Subnet2의 IP 범위는 10.0.2.0/24이므로 여기에서는 IP 10.0.2.4가 사용됩니다.

참고 : 감시 노드에는 기본 디스크 구성이 좋습니다. 두 번째 디스크는 필요하지 않습니다.

감시 노드에 태그를 지정합니다.

3 개의 인스턴스를 프로비저닝하는 데 약간의 시간이 걸릴 수 있습니다. 완료되면 EC2 콘솔에서 실행중인 것으로 표시됩니다.

7 단계 : 탄력적 IP 생성

그런 다음 외부에서 인스턴스에 연결하는 데 사용할 공개 IP 주소 인 탄력적 IP를 만듭니다. 왼쪽 메뉴에서 탄력적 IP를 선택한 다음 "새 주소 할당"을 클릭합니다.

 

새로 생성 된 탄력적 IP를 선택하고 마우스 오른쪽 버튼을 클릭 한 다음 "Associate Address"를 선택합니다.

이 탄력적 IP를 Node1과 연결합니다.

인터넷 액세스를 원하거나 직접 SSH / VNC 할 수 있도록하려면 다른 두 인스턴스에 대해이 작업을 반복합니다.

8 단계 : 가상 IP에 대한 경로 항목 생성

이 시점에서 3 개의 인스턴스가 모두 생성되었으며 클러스터의 가상 IP가 작동하려면 라우팅 테이블을 한 번 더 업데이트해야합니다. 이 다중 서브넷 클러스터 구성에서 가상 IP는 VPC에 할당 된 CIDR 범위 밖에 있어야합니다.

트래픽을 클러스터의 가상 IP (10.1.0.10), 기본 클러스터 노드 (Node1)로 보내는 새 경로를 정의합니다.

VPC 대시 보드에서 라우팅 테이블을 선택하고 편집을 클릭합니다. 대상이 Node1 인 "10.1.0.10/32"에 대한 경로를 추가합니다.

9 단계 : ENI에 대한 소스 / 대상 확인 비활성화

다음으로 클러스터 노드의 ENI (Elastic Network Interface)에 대한 소스 / 대상 확인을 사용 중지합니다. 이는 인스턴스가 클러스터의 가상 IP 주소에 대한 네트워크 패킷을 수락하기 위해 필요합니다.

모든 ENI에 대해이 작업을 수행하십시오.

“Network Interfaces”를 선택하고 ENI를 마우스 오른쪽 버튼으로 클릭 한 다음“Change Source / Dest Check”를 선택합니다.

"Disabled"선택 :

10 단계 : 액세스 키 ID 및 보안 액세스 키 얻기

가이드의 뒷부분에서 클러스터 소프트웨어는 AWS 명령 줄 인터페이스 (CLI)를 사용하여 클러스터의 가상 IP에 대한 라우팅 테이블 항목을 조작하여 트래픽을 활성 클러스터 노드로 리디렉션합니다. 이 기능이 작동하려면 AWS CLI가 올바르게 인증 할 수 있도록 액세스 키 ID와 보안 액세스 키를 얻어야합니다.

EC2 대시 보드의 오른쪽 상단에서 이름을 클릭하고 아래 드롭 다운에서 "보안 자격 증명"을 선택합니다.

표의 "액세스 키 (액세스 키 ID 및 보안 액세스 키)"섹션을 확장하고 "새 액세스 키 만들기"를 클릭합니다. 키 파일을 다운로드하여 안전한 위치에 저장하십시오.

11 단계 : Linux OS 구성

Linux 인스턴스에 연결합니다.

새로 생성 된 Linux 인스턴스 (SSH를 통해)에 연결하려면 인스턴스를 마우스 오른쪽 버튼으로 클릭하고 "연결"을 선택합니다. 그러면 인스턴스에 연결하기위한 지침이 표시됩니다. 이전 단계에서 생성 / 다운로드 한 개인 키 파일이 필요합니다.

예:

여기에서 잠시 동안 EC2 대시 보드를 떠나 명령 줄에서 손을 더럽힐 것입니다. Linux 관리자로서 지금까지는 익숙해야합니다.

AWS의 Linux VM (또는 기본 "ec2-user"계정)에 대한 루트 암호가 제공되지 않으므로 연결 한 후 "sudo"명령을 사용하여 루트 권한을 얻습니다.

$ sudo su –

DNS 서버를 이미 설정하지 않은 경우 3 개의 서버 모두에 호스트 파일 항목을 생성하여 nameEdit / etc / hosts로 서로를 올바르게 해결할 수 있도록합니다.

/ etc / hosts 파일 끝에 다음 행을 추가하십시오.

10.0.0.4 노드 1
10.0.1.4 노드 2
10.0.2.4 증인
10.1.0.10 mysql-vip

SELinux 비활성화

/ etc / sysconfig / linux를 편집하고“SELINUX = disabled”를 설정합니다.

# vi / etc / sysconfig / selinux

 

#이 파일은 시스템에서 SELinux의 상태를 제어합니다. # SELINUX =는 다음 세 가지 값 중 하나를 취할 수 있습니다.

# 시행 – SELinux 보안 정책이 시행됩니다.

# permissive – SELinux는 강제하는 대신 경고를 출력합니다.

# disabled – SELinux 정책이로드되지 않았습니다.

SELINUX = 비활성화

# SELINUXTYPE =은 다음 두 값 중 하나를 사용할 수 있습니다.

# 타겟팅 – 타겟팅 된 프로세스가 보호됨, # mls – 다단계 보안 보호.

SELINUXTYPE = 타겟팅

호스트 이름 설정

기본적으로 이러한 Linux 인스턴스에는 "ip-10-0-0-4.us-west-2.compute.internal"과 같이 서버의 IP 주소를 기반으로하는 호스트 이름이 있습니다.

호스트 이름을 "정상적인"방법 (예 : / etc / sysconfig / network 편집 등)으로 수정하려고하면 재부팅 할 때마다 원래 이름으로 되돌아갑니다 !! 재부팅 후 호스트 이름을 실제로 정적으로 유지하는 방법을 설명하는 AWS 토론 포럼에서 훌륭한 스레드를 찾았습니다.

세부 정보 : https://forums.aws.amazon.com/message.jspa?messageID=560446

“/etc/cloud/cloud.cfg”파일에서 호스트 이름을 설정하는 모듈을 주석 처리합니다. 다음 모듈은 #을 사용하여 주석 처리 할 수 있습니다.

# – set_hostname

# – update_hostname

다음으로 / etc / hostname에서 호스트 이름도 변경하십시오.

클러스터 노드 재부팅

SELinux가 비활성화되고 호스트 이름 변경 사항이 적용되도록 3 개의 인스턴스를 모두 재부팅합니다.

VNC (및 관련 패키지) 설치 및 구성

Linux 서버의 GUI에 액세스하고 나중에 클러스터를 설치 및 구성하려면 VNC 서버와 몇 가지 다른 필수 패키지를 설치하십시오 (클러스터 소프트웨어에는 redhat-lsb 및 패치 rpms 필요).

# yum groupinstall“X Window System”

# yum groupinstall 'GUI 포함 서버'

# yum install tigervnc-server xterm wget unzip patch redhat-lsb

# vncpasswd

다음 URL은 RHEL 7 / CentOS 7 : For RHEL 7.x / CentOS7.x에서 VNC 서버를 실행하는 데 유용한 가이드입니다.

https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-remote-access-for-the- gnome-desktop-on-centos-7

참고 :이 예시 구성은 디스플레이 2 (: 2, 일명 포트 5902) 및 루트 (안전하지 않음)에서 VNC를 실행합니다. 그에 따라 조정하십시오!

# cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:2.serv

# vi /etc/systemd/system/vncserver@:2.service

[Service]

유형 = 포킹

# /tmp/.X11-unix 환경에서 기존 파일 정리 ExecStartPre = / bin / sh -c‘/ usr / bin / vncserver -kill % i> / dev / null 2> & 1 || :’

ExecStart = / sbin / runuser -l root –c“/ usr / bin / vncserver % i –geometry 1024 × 768”PIDFile = / root / .vnc / % H % i.pid

ExecStop = / bin / sh -c‘/ usr / bin / vncserver -kill % i> / dev / null 2> & 1 || :’

# systemctl 데몬 새로 고침

# systemctl 사용 vncserver @ : 2.service

# vncserver : 2 -geometry 1024 × 768

RHEL / CentOS 6.x 시스템의 경우 :

# vi / etc / sysconfig / vncservers

 

VNCSERVERS =”2 : root”VNCSERVERARGS [2]=”-geometry 1024 × 768 ″

 

# 서비스 vncserver 시작

# chkconfig vncserver on

VNC 클라이언트를 열고 <ElasticIP : 2>에 연결합니다. 얻을 수 없다면 Linux 방화벽이 방해가 될 수 있습니다. 여기에서 사용중인 VNC 포트 (포트 5902)를 열거 나 지금은 방화벽을 비활성화합니다 (생산 환경에 권장되지 않음).

# systemctl 방화벽 중지

# systemctl 방화벽 사용 중지

"데이터"디스크 분할 및 포맷

Linux 인스턴스가 시작되고 보호 할 애플리케이션 데이터를 저장하기 위해 각 클러스터 노드에 추가 디스크가 추가되었을 때. 이 경우 MySQL 데이터베이스입니다.

두 번째 디스크는 / dev / xvdb로 나타나야합니다. "fdisk -l"명령을 실행하여 확인할 수 있습니다. 당신은 그것을 볼 수 있습니다
/ dev / xvda (OS)가 이미 사용되고 있습니다.

# fdisk -l

# 시작 끝 크기 유형 이름 디스크 / dev / xvda : 10.7GB, 10737418240 바이트, 20971520 섹터 단위 = 1 * 512 = 512 바이트 섹터
섹터 크기 (논리 / 물리) : 512 바이트 / 512 바이트 I / O 크기 (최소 / 최적) : 512 바이트 / 512 바이트 디스크 레이블 유형 : gpt

1 2048 4095 1M BIOS 부팅 부분
2 4096 20971486 10G Microsoft 기본
디스크 / dev / xvdb : 2147MB, 2147483648 바이트, 4194304 섹터 단위 = 1 * 512 = 512 바이트의 섹터
섹터 크기 (논리 / 물리) : 512 바이트 / 512 바이트 I / O 크기 (최소 / 최적) : 512 바이트 / 512 바이트

여기서는 파티션 (/ dev / xvdb1)을 만들고 포맷 한 다음 MySQL의 기본 위치에 마운트합니다.
/ var / lib / mysql. "node1"및 "node2"모두에서 다음 단계를 수행하십시오.

# fdisk / dev / xvdb

fdisk (util-linux 2.23.2)에 오신 것을 환영합니다.

 

변경 사항은 작성하기로 결정할 때까지 메모리에만 남아 있습니다. 쓰기 명령을 사용하기 전에주의하십시오.

 

장치에 인식 된 파티션 테이블이 없습니다.

디스크 식별자 0x8c16903a로 새 DOS 디스크 레이블을 작성합니다.

 

명령어 (m for help) : n

파티션 유형 :

p 기본 (기본 0 개, 확장 0 개, 무료 4 개) e 확장

선택 (기본값 p) : p

파티션 번호 (1-4, 기본값 1) : 1

첫 번째 섹터 (2048-4194303, 기본값 2048) : <enter>

기본값 2048 사용

마지막 섹터, + sectors 또는 + size {K, M, G} (2048-4194303, 기본값 4194303) : <enter>

기본값 4194303 사용

Linux 유형 및 크기 2GiB의 파티션 1이 설정 됨

 

Command (m for help) : w

파티션 테이블이 변경되었습니다!

ioctl ()을 호출하여 파티션 테이블을 다시 읽습니다. 디스크 동기화.

# mkfs.ext4 / dev / xvdb1
# mkdir / var / lib / mysql

node1에서 파일 시스템을 마운트합니다.

# 마운트 / dev / xvdb1 / var / lib / mysql

EC2 API 도구 (EC2 CLI)는 각 클러스터 노드에 설치해야 클러스터 소프트웨어가 나중에 라우팅 테이블을 조작하여 가상 IP에 연결할 수 있습니다.

12 단계 : EC2 API 도구 설치

다음 URL은이를 설정하는 훌륭한 가이드입니다.

http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/set-up-ec2-cli-linux.html

주요 단계는 다음과 같습니다.
CLI 도구를 다운로드하고 압축을 풀고 표준 위치 (/ opt / aws)로 이동합니다.

# wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip

# ec2-api-tools.zip 압축을 풉니 다.

# mv ec2-api-tools-1.7.5.1 / / opt / aws /

# export EC2_HOME =”/ opt / aws”

Java가 아직 설치되어 있지 않은 경우 (확인하려면 "which java"실행) 설치합니다.

# yum install java-1.8.0-openjdk

# export JAVA_HOME =”/ usr / lib / jvm / java-1.8.0-openjdk-1.8.0.71-

예 (RHEL 7.2 시스템의 기본 구성 기준. 그에 따라 조정)

AWS 액세스 키와 AWS 보안 키가 필요합니다. 이러한 값은 나중에 클러스터 설정 중에도 필요하므로 편리하게 유지하십시오! 자세한 내용은 다음 URL을 참조하십시오.

https://console.aws.amazon.com/iam/home?#security_credential

# export AWS_ACCESS_KEY = your-aws-access-key-id

# export AWS_SECRET_KEY = your-aws-secret-key

CLI 유틸리티 기능 테스트 :

# / opt / aws / bin / ec2-describe-regions
지역 eu-west-1 ec2.eu-west-1.amazonaws.com
지역 ap-southeast-1 ec2.ap-southeast-1.amazonaws.com
지역 ap-southeast-2 ec2.ap-southeast-2.amazonaws.com
지역 eu-central-1 ec2.eu-central-1.amazonaws.com
지역 ap-northeast-2 ec2.ap-northeast-2.amazonaws.com
지역 ap-northeast-1 ec2.ap-northeast-1.amazonaws.com
지역 us-east-1 ec2.us-east-1.amazonaws.com
지역 sa-east-1 ec2.sa-east-1.amazonaws.com
지역 us-west-1 ec2.us-west-1.amazonaws.com
지역 us-west-2 ec2.us-west-2.amazonaws.com

13 단계 : MySQL 설치 및 구성

다음으로 MySQL 패키지를 설치하고 샘플 데이터베이스를 초기화 한 다음 MySQL의 "루트"비밀번호를 설정합니다. RHEL7.X에서 MySQL 패키지는 MariaDB 패키지로 대체되었습니다.

"node1"에서 :

# yum mariadb mariadb-server 설치

# 마운트 / dev / xvdb1 / var / lib / mysql

# / usr / bin / mysql_install_db –datadir =”/ var / lib / mysql /”–user = mysql

# mysqld_safe –user = root –socket = / var / lib / mysql / mysql.sock –port = 3306 –datadi

#

# # 참고 :이 다음 명령은 모든 호스트에서 원격 연결을 허용합니다.  좋은 # echo "update user set Host =’%’여기서 Host =’node1 ′; 플러시 권한 | mysql mys #

# #MySQL의 루트 비밀번호를‘SIOS’로 설정

# echo“update user set Password = PASSWORD (‘SIOS’) where User =’root’; 플러시

MySQL 구성 파일을 생성합니다. 데이터 디스크 (나중에 복제됩니다.
/var/lib/mysql/my.cnf). 예:

# vi /var/lib/mysql/my.cnf

 

[mysqld] datadir = / var / lib / mysql

소켓 = / var / lib / mysql / mysql.sock

pid-file = / var / run / mariadb / mariadb.pid user = root

port = 3306

# 다양한 보안 위험을 방지하기 위해 심볼릭 링크를 비활성화하는 것이 좋습니다. 심볼릭 링크 = 0

[mysqld_safe]

log-error = / var / log / mariadb / mariadb.log pid-file = / var / run / mariadb / mariadb.pid

 

[client] 사용자 = 루트 암호 = SIOS

원래 MySQL 구성 파일이있는 경우 옆으로 이동합니다.

# mv /etc/my.cnf /etc/my.cnf.orig

“node2”에서는 MariaDB / MySQL 패키지 만 설치하면됩니다. 다른 단계는 필요하지 않습니다. "node2"에서 :

[root@node2 ~]# yum mariadb mariadb-server 설치

14 단계 : 클러스터 설치 및 구성

이제 클러스터를 설치하고 구성 할 준비가되었습니다. Linux 용 SIOS Protection Suite (일명 SPS-Linux)는이 가이드에서 클러스터링 기술로 사용됩니다. 단일 통합 솔루션에서 고 가용성 장애 조치 클러스터링 기능 (LifeKeeper)과 실시간 블록 수준 데이터 복제 (DataKeeper)를 모두 제공합니다. SPS-Linux를 사용하면 "SANLess"클러스터 (일명 "비공유"클러스터)를 배포 할 수 있습니다. 즉, EC2 인스턴스의 경우처럼 클러스터 노드에는 공유 스토리지가 없습니다.

Linux 용 SIOS Protection Suite 설치

VM 3 개 (node1, node2, 감시) 모두에서 다음 단계를 수행합니다.

SPS-Linux 설치 이미지 파일 (sps.img)을 다운로드하고 평가판 라이센스를 얻거나 영구 라이센스를 구입하십시오. 자세한 내용은 SIOS에 문의하십시오.

루프백 마운트하고 루트 (또는 루트 쉘을 얻으려면 먼저 "sudo su-")로 내부에서 "setup"스크립트를 실행합니다. 예 :

# mkdir / tmp / install

# mount -o loop sps.img / tmp / install

# cd / tmp / install

# ./설정

설치 스크립트가 진행되는 동안 여러 질문에 답하라는 메시지가 표시됩니다. 거의 모든 화면에서 Enter 키를 눌러 기본값을 적용합니다. 다음 예외에 유의하십시오.

  • "고 가용성 NFS"라는 화면에서 고 가용성 NFS 서버를 만들지 않을 것이므로 "n"을 선택할 수 있습니다.
  • 설치 스크립트가 끝날 무렵 지금 또는 나중에 평가판 라이센스 키를 설치하도록 선택할 수 있습니다. 나중에 라이센스 키를 설치하므로이 시점에서 "n"을 안전하게 선택할 수 있습니다.
  • "설정"의 마지막 화면에서 화면에 표시된 목록에서 설치할 ARK (응용 프로그램 복구 키트, 즉 "클러스터 에이전트")를 선택합니다.
    • ARK는 "node1"및 "node2"에서만 필요합니다. "witness"에 설치할 필요는 없습니다. 위쪽 / 아래쪽 화살표로 목록을 탐색하고 스페이스 바를 눌러 다음을 선택하십시오.
        • lkDR – Linux 용 DataKeeper
        • lkSQL – LifeKeeper MySQL RDBMS 복구 키트
      • 그러면“node1”및“node2”에 다음과 같은 추가 RPM이 설치됩니다.
        • steeleye-lkDR-9.0.2-6513.noarch.rpm steeleye-lkSQL-9.0.2-6513.noarch.rpm

Witness / Quorum 패키지 설치

LifeKeeper 코어의 기존 장애 조치 프로세스와 결합 된 LifeKeeper 용 Quorum / Witness Server 지원 패키지 (steeleye-lkQWK)를 사용하면 전체 네트워크 장애가 일반적 일 수있는 상황에서보다 확실하게 시스템 장애 조치를 수행 할 수 있습니다. 즉, "분할 브레인"상황의 위험을 크게 줄이면서 장애 조치를 수행 할 수 있습니다.

3 개 노드 (node1, node2, witness) 모두에 Witness / Quorum rpm을 설치합니다.

# cd / tmp / install / quorum

# rpm -Uvh steeleye-lkQWK-9.0.2-6513.noarch.rpm

3 개 노드 (node1, node2, Witness) 모두에서 / etc / default / LifeKeeper를 수정하고 NOBCASTPING = 1로 설정합니다.
Witness 서버 ( 'witness')에서만 / etc / default / LifeKeeper를 수정하고 WITNESS_MODE = off / none을 설정합니다.

EC2 복구 키트 패키지 설치

SPS-Linux는 리소스가 서로 다른 가용성 영역 및 지역의 노드간에 장애 조치를 취할 수 있도록하는 특정 기능을 제공합니다. 여기서 EC2 복구 키트 (즉, 클러스터 에이전트)는 가상 IP에 대한 연결이 활성 클러스터 노드로 라우팅되도록 라우팅 테이블을 조작하는 데 사용됩니다.

EC2 rpm (node1, node2)을 설치합니다.

# cd / tmp / install / amazon

# rpm -Uvh steeleye-lkECC-9.0.2-6513.noarch.rpm

라이센스 키 설치

3 개 노드 모두에서 "lkkeyins"명령을 사용하여 SIOS에서 얻은 라이센스 파일을 설치합니다.

# / opt / LifeKeeper / bin / lkkeyins <파일 경로> / <파일 이름> .lic

LifeKeeper 시작

3 개 노드 모두에서 "lkstart"명령을 사용하여 클러스터 소프트웨어를 시작합니다.

# / opt / LifeKeeper / bin / lkstart

LifeKeeper GUI에 대한 사용자 권한 설정

3 개의 노드 모두에서 새 Linux 사용자 계정 (예 :이 예에서는 "tony")을 만듭니다. / etc / group을 편집하고 "tony"사용자를 "lkadmin"그룹에 추가하여 LifeKeeper GUI에 대한 액세스 권한을 부여합니다. 기본적으로 "root"만 그룹의 구성원이며 여기에는 루트 암호가 없습니다.

 

# useradd tony

# 암호 토니

# vi / etc / group

 

lkadmin : x : 1001 : 루트, 토니

LifeKeeper GUI 열기

node1의 탄력적 IP (공용 IP) 주소에 VNC 연결을 설정합니다. 위의 VNC 구성에 따라 앞에서 지정한 VNC 암호를 사용하여 <Public_IP> : 2에 연결합니다. 로그인 한 후 터미널 창을 열고 다음 명령을 사용하여 LifeKeeper GUI를 실행하십시오.

# / opt / LifeKeeper / bin / lkGUIapp &

첫 번째 클러스터 노드 ( "node1")에 연결하라는 메시지가 표시됩니다. VM 생성 중에 지정된 Linux 사용자 ID 및 비밀번호를 입력하십시오.

다음으로, 다음 스크린 샷에 강조 표시된 "서버에 연결"버튼을 클릭하여 "node2"와 "witness"모두에 연결합니다.

이제 GUI에 3 개의 서버가 모두 온라인 상태이고 정상임을 나타내는 녹색 확인 표시 아이콘이 표시됩니다.

통신 경로 생성

"node1"을 마우스 오른쪽 버튼으로 클릭하고 통신 경로 생성을 선택합니다.

"node2"와 "witness"를 모두 선택한 다음 마법사를 따릅니다. 그러면 다음 사이에 통신 경로가 생성됩니다.


node1 및 node2 node1 및 감시


node2와 감시 사이에 통신 경로를 생성해야합니다. "node2"를 마우스 오른쪽 단추로 클릭하고 통신 경로 작성을 선택하십시오. 마법사를 따라 원격 서버로 "witness"를 선택합니다.


이 시점에서 다음과 같은 통신 경로가 생성되었습니다.

node1 <—> node2 node1 <—> 감시 node2 <—> 감시

서버 앞의 아이콘이 녹색 "확인 표시"에서 노란색 "위험 표시"로 변경되었습니다. 이는 노드간에 통신 경로가 하나뿐이기 때문입니다.

VM에 여러 NIC가있는 경우 (여러 NIC로 Azure VM을 만드는 방법에 대한 정보는 여기에서 찾을 수 있지만이 문서에서는 다루지 않음) 각 서버간에 중복 통신 경로를 만듭니다.


경고 아이콘을 제거하려면보기 메뉴로 이동하여 "통신 경로 중복 경고"를 선택 취소하십시오.


결과:

 

통신 경로 확인

클러스터 자원의 상태를 보려면 "lcdstatus"명령을 사용하십시오. 다음 명령을 실행하여 관련된 다른 두 서버에 대한 각 노드에서 통신 경로를 올바르게 작성했는지 확인하십시오.

# / opt / LifeKeeper / bin / lcdstatus -q -d node1
머신 네트워크 주소 / 장치 상태 PRIO node2 TCP 10.0.0.4/10.0.1.4

ALIVE 1 감시 TCP 10.0.0.4/10.0.2.4 ALIVE 1
# / opt / LifeKeeper / bin / lcdstatus -q -d node2
머신 네트워크 주소 / 장치 상태 PRIO node1 TCP 10.0.1.4/10.0.0.4

ALIVE 1 감시 TCP 10.0.1.4/10.0.2.4 ALIVE 1
# / opt / LifeKeeper / bin / lcdstatus -q -d 감시

머신 네트워크 주소 / 장치 상태 PRIO node1 TCP 10.0.2.4/10.0.0.4
ALIVE 1 node2 TCP 10.0.2.4/10.0.1.4 ALIVE 1

데이터 복제 클러스터 리소스 (예 : 거울)

다음으로 데이터 복제 리소스를 생성하여 / var / lib / mysql 파티션을 node1 (소스)에서 node2 (대상)로 복제합니다. "녹색 더하기"아이콘을 클릭하여 새 리소스를 만듭니다.


다음 선택 사항으로 마법사를 따릅니다.

복구 키트를 선택하십시오 : 데이터 복제 스위치 백 유형 : 지능형

서버 : node1

계층 유형 : 기존 파일 시스템 복제

기존 마운트 포인트 : / var / lib / mysql

데이터 복제 리소스 태그 : datarep-mysql

파일 시스템 리소스 탭 : / var / lib / mysql

비트 맵 파일 : (기본값)

비동기 복제 활성화 : 아니요

리소스가 생성되면 "확장"(즉, 백업 서버 정의) 마법사가 나타납니다.

다음 선택을 사용하십시오.

대상 서버 : node2 스위치 백 유형 : 지능형 템플릿 우선 순위 : 1

대상 우선 순위 : 10 대상 디스크 : / dev / xvdb1

데이터 복제 리소스 태그 : datarep-mysql 비트 맵 파일 : (기본값)

복제 경로 : 10.0.0.4/10.0.1.4 마운트 지점 : / var / lib / mysql

루트 태그 : / var / lib / mysql

클러스터는 다음과 같습니다.

가상 IP 생성

다음으로 가상 IP 클러스터 리소스를 만듭니다. "녹색 더하기"아이콘을 클릭하여 새 리소스를 만듭니다.


마법사를 따라 다음 선택 사항으로 IP 리소스를 만듭니다.

복구 키트 선택 : IP 스위치 백 유형 : 지능형 IP 리소스 : 10.1.0.10

넷 마스크 : 255.255.255.0

네트워크 인터페이스 : eth0

IP 리소스 태그 : ip-10.1.0.10

다음 선택 사항으로 IP 자원을 확장하십시오.

스위치 백 유형 : 지능형 템플릿 우선 순위 : 1

타겟 우선 순위 : 10

IP 리소스 : 10.1.0.10

넷 마스크 : 255.255.255.0

네트워크 인터페이스 : eth0

IP 리소스 태그 : ip-10.1.0.10

클러스터는 이제 미러 및 IP 리소스가 모두 생성 된 다음과 같이 표시됩니다.

IP 리소스에 대한 Ping 목록 구성

기본적으로 SPS-Linux는 브로드 캐스트 핑을 수행하여 IP 리소스의 상태를 모니터링합니다. 많은 가상 및 클라우드 환경에서 브로드 캐스트 핑이 작동하지 않습니다. 이전 단계에서 "NOBCASTPING = 1"을
/ etc / default / LifeKeeper는 브로드 캐스트 핑 검사를 해제합니다. 대신 핑 목록을 정의합니다.

이 IP 리소스에 대한 IP 상태 확인 중에 핑할 IP 주소 목록입니다.

이 가이드에서는 감시 서버 (10.0.2.4)를 핑 목록에 추가합니다.

IP 리소스 (ip-10.1.0.10)를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.

처음에는 10.1.0.0 서브넷에 대해 핑 목록이 구성되어 있지 않음을 알 수 있습니다. "Ping 목록 수정"을 클릭합니다.

"10.0.2.4"(감시 서버의 IP 주소)를 입력하고 "주소 추가"를 클릭 한 다음 마지막으로 "목록 저장"을 클릭합니다.


IP 속성 패널로 돌아가서 10.0.2.4가 핑 목록에 추가되었는지 확인할 수 있습니다. 확인을 클릭하여 창을 닫습니다.

MySQL 리소스 계층 만들기

다음으로 MySQL 클러스터 리소스를 생성합니다. MySQL 리소스는 MySQL 데이터베이스의 중지 / 시작 / 모니터링을 담당합니다.

MySQL 리소스를 만들기 전에 데이터베이스가 실행 중인지 확인하십시오. “ps -ef | grep sql”을 확인하십시오.

실행 중이라면 할 일이 없습니다. 그렇지 않은 경우 데이터베이스 백업을 시작하십시오.

# mysqld_safe –user = root –socket = / var / lib / mysql / mysql.sock –port = 3306 –datadi

마법사를 따라 다음 선택 항목으로 IP 리소스를 생성합니다. 생성하려면 "녹색 더하기"아이콘을 클릭하여 새 리소스를 생성합니다.

복구 키트 선택 : MySQL 데이터베이스 전환 유형 : 지능형 서버 : node1

my.cnf의 위치 : / var / lib / mysql

MySQL 실행 파일의 위치 : / usr / bin

데이터베이스 태그 : mysql

다음 선택 사항으로 IP 자원을 확장하십시오.

대상 서버 : node2 스위치 백 유형 : 지능형 템플릿 우선 순위 : 1

타겟 우선 순위 : 10

결과적으로 클러스터는 다음과 같이 보입니다. 데이터 복제 리소스는 항상 데이터베이스보다 먼저 온라인 상태가되도록 데이터베이스 아래로 자동으로 이동되었습니다 (종속성이 자동으로 생성됨).

장애 조치시 라우팅 테이블을 관리하기위한 EC2 리소스 생성

SPS-Linux는 리소스가 서로 다른 가용성 영역 및 지역의 노드간에 장애 조치를 취할 수 있도록하는 특정 기능을 제공합니다. 여기서 EC2 복구 키트 (즉, 클러스터 에이전트)는 가상 IP에 대한 연결이 활성 클러스터 노드로 라우팅되도록 라우팅 테이블을 조작하는 데 사용됩니다.

만들려면 "녹색 더하기"아이콘을 클릭하여 새 리소스를 만듭니다.


마법사를 따라 다음 선택 사항으로 EC2 리소스를 생성합니다.

복구 키트 선택 : Amazon EC2 스위치 백 유형 : 지능형 서버 : node1

EC2 홈 : / opt / aws

EC2 URL : ec2.us-west-2.amazonaws.com

AWS 액세스 키 : (이전에 얻은 액세스 키 입력) AWS 보안 키 : (이전에 얻은 보안 키 입력) EC2 리소스 유형 : RouteTable (백엔드 클러스터)

IP 리소스 : ip-10.1.0.10

EC2 리소스 태그 : ec2-10.1.0.10

다음 선택 사항으로 IP 자원을 확장하십시오.

대상 서버 : node2 스위치 백 유형 : 지능형 템플릿 우선 순위 : 1

타겟 우선 순위 : 10

EC2 리소스 태그 : ec2-10.1.0.10

클러스터는 다음과 같습니다. EC2 리소스가 IP 리소스 아래에 어떻게 있는지 확인하십시오.

IP 리소스와 MySQL 데이터베이스 리소스 사이에 종속성 만들기

IP 리소스와 MySQL 데이터베이스 리소스 사이에 종속성을 만들어 그룹으로 함께 장애 조치합니다. "mysql"리소스를 마우스 오른쪽 버튼으로 클릭하고 "종속성 생성"을 선택합니다.

다음 화면에서 "ip-10.1.0.10"리소스를 종속성으로 선택합니다. 다음을 클릭하고 마법사를 계속합니다.

이 시점에서 SPS-Linux 클러스터 구성이 완료되었습니다. 리소스 계층 구조는 다음과 같습니다.

15 단계 : 클러스터 연결 테스트

이제 모든 Amazon EC2 및 클러스터 구성이 완료되었습니다! 클러스터 리소스는 현재 node1에서 활성화되어 있습니다.

미러링 모니터 서버 (또는 다른 Linux 인스턴스가있는 경우)에서 클러스터에 대한 연결을 테스트하여 미러링 모니터 서버 "sudo su-"로 연결하여 루트 액세스 권한을 얻습니다. 필요한 경우 mysql 클라이언트를 설치합니다.

[root@witness ~]# yum -y mysql 설치

클러스터에 대한 MySQL 연결을 테스트합니다.

[root@witness ~]# mysql –host = 10.1.0.10 mysql -u root -p

다음 MySQL 쿼리를 실행하여 활성 클러스터 노드의 호스트 이름을 표시합니다.

MariaD[mysql]B> @@ hostname 선택;

++

| @@ hostname |

++

| node1 |

++

세트의 행 1 개 (0.00 초) MariaDB[mysql]>

LifeKeeper GUI를 사용하여 Node1에서 장애 조치-> Node2 ″. node2 아래의 mysql 리소스를 마우스 오른쪽 버튼으로 클릭하고 "In Service…"를 선택합니다.

장애 조치가 완료된 후 MySQL 쿼리를 다시 실행합니다. MySQL 클라이언트가 세션이 손실되었음을 감지하고 (장애 조치 중에) 자동으로 다시 연결됩니다.

다음 MySQL 쿼리를 실행하여 활성 클러스터 노드의 호스트 이름을 표시하고 이제 "node2"가 활성 상태인지 확인합니다.

MariaD[mysql]B> @@ hostname 선택;

오류 2006 (HY000) : MySQL 서버가 사라졌습니다. 연결이 없습니다. 다시 연결하는 중…

연결 ID : 12

현재 데이터베이스 : mysql

++

| @@ hostname |

++

| node2 |

++

세트의 행 1 개 (0.53 초) MariaDB[mysql]>

SIOS의 허가를 받아 복제

 
8월 11, 2020

영화에서 클라우드 고 가용성의 교훈

영화에서 클라우드 고 가용성의 교훈

영화에서 클라우드 고 가용성의 교훈

jmlalonde.com의 Joseph Lalonde는 Hancock, The Greatest Showman, Frozen II와 같은 인기 영화의 리더십 교훈을 강조하는 블로그를 운영하고 있습니다.  Joseph의 영감을주는 리더십 강의에 힘 입어 Disney의 Frozen II에서 클라우드 마이그레이션에 대한 4 가지 고 가용성 강의가 있습니다.

Disney의 Frozen II 및 클라우드 마이그레이션 강의

Disney의 애니메이션 어드벤처 Frozen II에서 Anna, Elsa, Kristoff, Olaf, Sven 캐릭터는 Arendelle을 떠나 마법에 걸린 땅의 고대 가을 숲으로 여행합니다. 모험에서 그들은 왕국을 구하기 위해 엘사의 힘의 기원을 찾기 시작했습니다.  여섯 소녀의 아버지에게 재미를주는 것 외에도이 영화는 리더십, 삶, 고 가용성 교훈으로 무르 익었습니다.

1.    적절한 도움 없이는 클라우드 마이그레이션을 시작할 수 없습니다.

엘사, 안나, 크리스토프, 올라프, 스벤이 신비한 목소리가 그들을 부르고있는 곳에 도착했을 때, 그들은 거대한 구름 밖에 서 있습니다.  올라프와 크리스토프가 들어 오려고하면 다시 튕겨 나가 격퇴됩니다.  엘사가 마법으로 클라우드에 접근 할 때에 만 포털이 열리고 들어갑니다.

클라우드로 마이그레이션 할 때 당신을 부르는 목소리가 많이있을 것입니다.  일부는 사용자를 AWS, Azure, GCP 또는 수많은 다른 사용자에게 손짓합니다.  그러나 어떤 방법을 사용하든 성공적인 참가를 위해서는 적절한 도움이 필요하다는 것을 알고 있어야합니다.  이 도움말에는 다음이 포함되어야합니다.

  • 플랫폼, 특히 네트워킹 측면에 대해 잘 알고있는 설계자
  • 애플리케이션 설치, 구성, 운영 및 유지 관리 특성을 이해하는 애플리케이션 관리자
  • 보안 및 OS 관리자
  • 클라우드 파트너 담당자
  • 고 가용성 아키텍처에서 중요한 애플리케이션을 배포하기위한 지식이 풍부한 가용성 전문가

2.    나이가 들면 일이 이해되지 않으므로 문서화하고 반복하십시오.

마법에 걸린 숲을 걷는 동안 올라프는 숲의 이상한 현상과 마법을 경험하기 시작합니다.  그는 노래를 시작합니다.

  • 내가 나이가 들면이 모든 게 이해가 될거야
    언젠가는 이것이 의미가 있음을 알게 될 것입니다.
  • 어느 날 내가 늙고 현명 할 때
  • 생각하고 깨달을 게
  • 이 모든 것이 완전히 정상적인 사건이라는 것을
  • 나이가 들면 모든 답을 얻 겠어

노래는 다음과 같이 마무리됩니다.

  • 네가 나이가 들면
  • 절대적으로 모든 것이 의미가 있습니다.
  • 이건 괜찮아

중지.  클라우드 여정을 시작할 때 상황이 이해가되지 않는 경우 시간을내어 이해가되도록하십시오.  민첩한 사고 방식을 사용하는 경우 단일 주제 또는 혼란 주제에 대한 조사 급증을 시작하십시오.  예를 들어, 현재 VPC, 보안 그룹, 가용 영역 또는 세트, 리전 또는 리전 대 리전 개념의 마법을 이해하지 못하는 경우 몇 달 후이 구성으로 돌아 오면 나중에이 개념이 훨씬 덜 의미가있을 것입니다. .  테스트 결과가 의미가 없으면 계속 진행하지 말고 다시 실행하세요.  또한 중요하다고 생각하는 세부 사항뿐만 아니라 6 개의 다른 프로젝트를 진행하고 마감일을 앞두고있는 나이든 당신이 모든 것을 이해하기 위해 알고 싶어 할 세부 사항을 문서화하는 것을 기억하십시오.

삼.    불에 뛰어 들지 마십시오. 적합한 클라우드 고 가용성 솔루션을 선택하십시오.

바람의 정령이 붓고 마법에 걸린 숲이 불의 정령에 불타 오릅니다.  불의 정령이 혼돈과 불을 퍼 뜨리면 엘사는 얼음 폭발로 돌진하여 불을 식히고이 영혼을 진정시킵니다.  그녀의 열심으로 안나는 언니 뒤에서 불을 만나 구원을 받아야합니다.  마침내 두 사람이 재회 할 때 Elsa는 그녀의 여동생에게“당신은 나를 따라 불속에 들어갈 수 없다”고 충고합니다.  열정적 인 Anna가 대답합니다.“내가 당신을 따라가는 것을 원하지 않습니까? 그럼 불에 맞서지 마세요!”

클라우드로 마이그레이션하고 적절한 가용성 솔루션을 선택하는 것은 테스트되지 않은 이론과 시나리오로 비현실적인 일정을 만들어 복잡하지 않고 스트레스를받을 수 있습니다.  배포 팀의 리더는 자신의 팀이 소방 훈련을 받기를 원하지 않으므로 고의로 부딪히지 마십시오.  계획을 세우십시오.  체크 포인트와 마일스톤을 설정합니다.  현실적인 위험 및 위험 관리 전략을 포함합니다.  공급 업체 및 파트너, 특히 팀과 자주 커뮤니케이션하십시오.  잘 테스트하고 백업 및 취소 계획을 이해합니다.

4.    클라우드 마이그레이션을 통해 가져온 과거에 얽매이지 마십시오.

영화 전반에 걸쳐 'All is Found'라는 노래가 쿨링 코러스와 함께 엮여 있습니다.“그녀의 소리에 깊이 빠져보세요. 너무 멀지 않으면 익사 할 것입니다.” Elsa는 영화가 절정에 달하고 과거에 대한 탐색과 탐구가 겨울 왕국을 떠나면서 깊은 곳으로 잠수합니다. 그녀의 마지막은 그녀의 여동생에게 경고하고 알리기 위해 폭발적인 숨을 헐떡입니다.

SIOS Technology Corp.의 고객 경험 팀장 중 한 명으로서 너무 많은 배포와 마이그레이션이 비교 함정에 갇히는 것을 목격했습니다.  "이전 데이터 센터에서는 우리"또는 "이전 시스템이 그렇게 할 수있었습니다."라는 문구가 사용됩니다. 고정 시스템, 전용 리소스, 대규모 팀, 특정 네트워킹 및 고비용, 고기능 SAN 스토리지로 구성된 기존 시스템이이를 수행 할 수 있다는 것은 사실 일 수 있습니다.  (하지만 사실은 때때로 커튼이 벗겨지는 것을 보았고 온 프레미스에서도 그렇게하지 않았습니다).  클라우드로 마이그레이션 할 때 클라우드에서 모방하는 것이 합당한 것과 그렇지 않은 것을 이해하십시오.  시스템이 온 프레미스 방식으로 설계된 이유를 이해하고 도움말 "강의 1과 강의 2의 학습을 통해 합리적인 결정을 내립니다.

마지막 수업으로 연결됩니다.

5.     온 프레미스와 클라우드라는 두 가지 왕국이 항상 존재합니다.

영화가 끝날 무렵 Anna는 언니 Elsa가 통치했던 Arendelle의 여왕이되고 Elsa는 Northuldra 사람들을 이끌고 있습니다.  한때 미스터리와 구름에 둘러싸여 숲속이나 그 근처에 머무르는 사람이 있고, 다른 사람은 익숙한 땅으로 돌아갑니다.

클라우드로의 마이그레이션과 고 가용성 전략을 고려할 때 항상 두 개의 왕국이 있음을 기억하십시오.  마이그레이션 전략은 클라우드 배포와 협력 할 온 프레미스 데이터 센터가 항상 필요하다는 점을 기억하는 것이 좋습니다.  예전만큼 넓지는 않지만 모든 워크로드 또는 중요 인프라를 클라우드 용으로 용도 변경하고 패키징 할 수있는 것은 아닙니다.  두 "왕국"을 모두 지원하고 활성화 할 수있는 HA 솔루션과 전략을 갖추는 것이 필수적입니다.

클라우드로 이동하려면 적절한 팀, 적절한 도구 및 적절한 솔루션, 그리고 화재없이 도달 할 수있는 전략과 계획이 필요합니다.  클라우드로 마이그레이션 할 때 기꺼이 과거에 맞서고 이해하며 거기에 갇히지 않도록 기억하십시오.  또한 Disney의 Frozen II의 두 자매처럼 모든 아름다운 엔터프라이즈 스토리에는 양면이 있다는 것을 기억하는 것이 좋습니다. 온 프레미스와 클라우드가 여러분의 것일 수도 있습니다.

— Cassius Rhue, VP, 고객 경험

SIOS의 허가를 받아 복제

 
8월 2, 2020

AWS EC2 애플리케이션 모니터링이 그렇게 어려운 이유는 무엇입니까?

AWS EC2 애플리케이션 모니터링이 그렇게 어려운 이유는 무엇입니까?

AWS EC2 애플리케이션 모니터링이 그렇게 어려운 이유는 무엇입니까?

축하합니다! 핵심 애플리케이션을 AWS 클라우드로 마이그레이션했습니다.  또는 새로운 "클라우드 네이티브"애플리케이션을 개발하여 클라우드에 호스팅하고 있습니다.  아마도 Amazon EC2의 확장 성과 탄력적 인 아키텍처를 활용하고있을 것입니다.  어느 쪽이든, 이제 해당 응용 프로그램이 계속 작동하고 있는지 또는 무언가가 발생하는 경우 신속하게 경고를 받으려고합니다.

무언가가 일어날 것입니다.  고객 데이터에 따르면 3 개의 EC2 인스턴스 만 사용하는 회사는 적어도 한 달에 한 번 다운 타임을 경험합니다.  이는 불행한 사용자가 자신의 응용 프로그램에 액세스 할 수 없음을 의미합니다. 진행 상황을 알려주는 모니터링 솔루션이 필요합니다.

EC2 애플리케이션 모니터링 솔루션의 범위를 좁히는 방법

완벽한 EC2 모니터링 솔루션을 찾기위한 첫 번째 단계는 요구 사항과 자체 기술 기능을 이해하는 것입니다.  모니터링 솔루션이 모두 같은 것은 아닙니다.

다양한 시스템을 모니터링하는 기능이 풍부한 솔루션에 관심이 있습니까? 아니면 EC2 환경과 같은 핵심 시스템 세트에 중점을 둔 제품입니까?

애플리케이션 모니터링 솔루션의 출력으로 무엇을 하시겠습니까? 개발자의 문제 해결에 도움이되도록 최대한 많은 정보를 원하십니까? 아니면 모든 장애에 대한 신속한 경고와 도움을 찾고 있습니까?

그리고 다른 응용 프로그램을 설치하고 관리하려는 기술적 인 욕구는 무엇입니까? 스크립팅을 좋아합니까? 아니면“놓고 잊어 버린”무언가를 원하십니까?

Google에서 "애플리케이션 성능 모니터링 솔루션"을 검색하면 1,170,000,000 개의 결과가 반환됩니다! Amazon AWS Marketplace로 이동하면 DevOps – 모니터링 범주에 453 개의 제품이 표시됩니다.  요구 사항과 자신의 기술적 기능을 명확하게 이해하면 검색 범위를 좁힐 수 있습니다.

Amazon CloudWatch 또는 다른 APM 솔루션을 사용하여 Amazon EC2에서 실행되는 애플리케이션 모니터링

Amazon EC2에서 애플리케이션을 호스팅하는 경우 Amazon CloudWatch 사용을 고려할 수 있습니다.   표준 및 맞춤 측정 항목에 어느 정도 익숙하십니까? Amazon CloudWatch를 제대로 실행하려면 상당한 기술 전문 지식이 필요합니다. Amazon CloudWatch는 시스템 전체의 성능 변화에 대응하고 리소스를 최적화하며 운영 상태에 대한 통일 된 관점을 제공하기 위해 데이터 및 실행 가능한 통찰력이 필요한 사용자를위한 훌륭한 솔루션입니다.  그러나이 모든 것은 Amazon CloudWatch를 올바르게 구성하고 관리하는 데 필요한 지식과 경험면에서 가격이 책정됩니다.

AppDynamics, Datadog, Dynatrace 또는 New Relic과 같이 시중에서 판매되는 많은 "APM"(Application Performance Monitoring) 솔루션 중 하나를 평가하고 획득 할 수 있습니다.  그러나 요구 사항을 명심하십시오.  얼마나 광범위하게 모니터링해야합니까? 그리고 그 정보로 무엇을하려고합니까? 당신은 경고에 압도 할 준비가 되셨습니까? 또한 많은 APM 솔루션은 문제를 정확히 지적하는 것 이상으로 복구하는 데 도움이되지 않습니다.  서비스를 수동으로 다시 시작하거나 인스턴스를 재부팅하려면 여전히 모든 것을 삭제해야합니다.

SIOS AppKeeper를 사용하여 Amazon EC2에서 실행되는 애플리케이션 모니터링

그러나 다른 방법이 있습니다.  SIOS AppKeeper는 EC2 인스턴스 및 해당 서비스를 자동으로 검색하도록 구성 할 수있는 SaaS 서비스입니다. 그런 다음 가동 중지 시간이 발생하면 자동으로 여러 작업을 수행합니다.  따라서 문제가 있음을 알리는 대신 문제가 발생했음을 알리고 자동으로 해결되었습니다.
Why-App_monitoring-hard-2-1024x470

SIOS AppKeeper는 매월 인스턴스 당 미화 40 달러로 시작합니다. AppKeeper를 설치하고 사용하는 것이 얼마나 쉬운 지 알아 보려면이 짧은 비디오를 시청하십시오.

AWS EC2 애플리케이션 모니터링이 그렇게 어려운 이유는 무엇입니까?

도쿄의 출판 회사 인 하비 재팬 (Hobby Japan)은 처음에 Amazon CloudWatch를 사용했지만 고객이 부족한 IT 팀은 경보에 충분히 빠르게 대응할 수 없었습니다. 그들은 자동화를 활용하고 SIOS AppKeeper로 옮겼습니다.  AppKeeper로 이전 한 이후 EC2 인스턴스에서 문제가 발생하거나 예기치 않은 다운 타임이 발생하지 않았습니다. Hobby Japan의 사례 연구에 대한 링크입니다.

클라우드 애플리케이션을 모니터링하는 것은 풀 타임 일이 아닙니다.  설치 및 사용이 쉽고 모니터링에 부담을주지 않으며 시스템 손상을 자동으로 관리하는 모니터링 솔루션이 필요합니다.  여기에 가입하여 SIOS AppKeeper의 14 일 무료 평가판을 사용해보십시오.
7월 30, 2020

기획은 기업 가용성과 행복한 결혼의 열쇠입니다

기획은 기업 가용성과 행복한 결혼의 열쇠입니다

기획은 기업 가용성과 행복한 결혼의 열쇠입니다

데이트와 도주 계획, 멋진 낭만적 인 저녁 식사는 배우자를 사랑하는 데 큰 도움이됩니다.  전 세계 거의 모든 지역에서 관계 개선을위한 팁이 가득한 세미나 및 워크샵.

그러나 SIOS Technology Corp.에서 제공하는 교육 세션을 청취하십시오. Edmond Melkomian Professional Services의 프로젝트 관리자는 저녁 식사 및 기념일 퇴각 계획 만이 배우자를 사랑하는 유일한 방법은 아니라는 점을 빠르게 알게됩니다.

Linux 용 SIOS Protection Suite의 최근 수업에서 Edmond는 계획, 계획, 계획 등 엔터프라이즈 세계에서 배우자를 사랑하는 데 도움이되는 세 가지 팁을 공유했습니다.

1.   엔터프라이즈 가용성 솔루션“계획 계획”

1. 엔터프라이즈 가용성 솔루션“계획 계획”

그의 과정에서 Edmond Melkomian은 학생들에게 엔터프라이즈 솔루션을 배포 할 때 가장 먼저해야 할 일의 이름을 물었습니다.  그의 대답은“계획, 계획, 계획”입니다. 분명해 보이지만 첫 번째 단계는 계획을 세우는 것입니다.  계획에 대한 적절한 시작은 이정표, 체크 포인트, 위험, 위험 완화 및 전략, 이해 관계자, 타임 라인, 이해 관계자 커뮤니케이션 계획과 같은 각 프로젝트 단계에 대한 세부 사항 개발을 포함합니다.  적절한 계획에는 킥오프, 사인 오프 및 폐쇄, 자원 (직원, 관리, 법률 / 계약)에 대한 세부 사항도 포함됩니다.

솔루션 라이프 사이클 전체에서 계획을 작성, 검토, 수정 및 업데이트하도록 계획하십시오.

2.   엔터프라이즈 가용성을 위해 배포 할 계획

배포 대상을 계획하십시오.  기업 인프라의 상당 부분이 현재 팀의 회사 수명 범위를 넘어서 존재할 수 있습니다.  클라우드로 마이그레이션하거나 가용성 전략을 업데이트 할 때 배포 대상에 대한 계획을 세우는 데는 시간과 노력이 필요합니다.  모든 중요 구성 요소, 네트워크, 컴퓨팅, 스토리지, 전원, 냉각 및 응용 프로그램에 중복성을 배치 할 수 있도록 계획에 집중하십시오.  모든 데이터 센터 및 클라우드 제공 업체는 일반적으로 냉각, 전원 및 네트워크 이중화를 시작합니다.

다수의 회사는 아키텍처 팀, 클라우드 솔루션 제공 업체, 가용성 전문가, 애플리케이션 아키텍트 및 마이그레이션 전문가를 제공하여 팀이 중요하고 때로는 숨겨진 종속성과 SPOF (Single Points of Failure)에 취약한 고위험 영역을 발견하도록 도와줍니다.  이 조사 작업은 가용성 전략에서 배포 및 / 또는 업데이트 대상에 대한 계획을 제공합니다.

배포해야 할 사항을 검토하도록 계획하십시오.

삼.   안정적인 가용성을 위해 QA / 사전 프로덕션 클러스터 유지 계획

SIOS Technology Corp. 개발 팀에 있었을 때 금요일 밤에 전화를 한 적이 있지만 열광적 인 고객을 잊지 않았습니다.  이달 초에 빈번한 고객이 새로운 소프트웨어 솔루션을 프로덕션 환경에 성공적으로 배포하지 못했습니다.  결과는 엄청난 실패였습니다.  그는 금요일 오후 4시 30 분 (EST)에 800 번으로 전화했습니다.  정확한 시간을 기억하는 이유는 무엇입니까? 금요일은 데이트 밤이었습니다.  아내와 저는 저녁 식사 계획, 대기중인 6 명의 소녀들을위한 베이비 시터 (시간별), 낭만적이고 편안한 저녁을 원합니다.  나는 전화가 울렸던 날을 향해 나 가려고했다.  시제 첫 시간 후, 우리는 백업 및 실행했다.  이 불행한 에피소드는 UAT 또는 QA 시스템을 유지함으로써 피하거나 완화 할 수있었습니다.

SIOS Technology Corp.의 고객 경험을위한 소프트웨어 엔지니어 인 Harrison Howell은 자신의 블로그 (6-common-cloud-migration-challenges)에서 온 프레미스의 한계가 더 이상 같은 한계가 아니라고 지적했습니다.

온-프레미스 시스템을 사용하는 고객은 리소스가 더 이상 제한 요소가 아니라는 점을 기억해야합니다. 클라우드에서 시스템은 손쉽게 온 프레미스가 아닌 프로덕션과 별도로 복사하고 실행할 수 있습니다. IT 리소스에 대한 주문형 액세스를 통해 HA 및 DR의 UAT는 "기본 노드 종료"이상으로 확장 할 수 있습니다. 네트워크가 파괴 될 수 있고, 커널이 패닉 될 수 있으며, 데이터베이스조차 손상 될 수 있으며,이 중 어느 것도 프로덕션에 영향을 미치지 않습니다! 이러한 시나리오를 식별하고 테스트하면 HA 및 DR 자세가 향상됩니다.

HA 및 DR 테스트를위한 UAT 시스템 배포 및 유지 관리 계획.  Harrison이 언급했듯이“식별 및 [issues]테스트”“H[your overall]A 및 DR 자세 개선”은 성공적인 데이트 밤의 가능성을 높입니다.

4.   정기적 인 유지 관리 및 업데이트 계획 (문서 포함)

마지막으로 Enterprise Availability를 유지하기 위해 정기적 인 유지 보수 및 업데이트 시간을 계획하십시오.  수익성과 성공을 유지하려면 기업의 가용성이 높아야합니다.  환경은 정체되지 않고 패치, 보안 업데이트, 확장 및 일반 유지 관리는 시작부터 은퇴까지 정기적으로 발생합니다.  기업에 업데이트 및 유지 관리를 통합하는 방법과시기에 대한 계획을 세우면 최신 상태를 유지할뿐만 아니라 작업을 수행하는 동안 위험과 중단 시간을 최소화 할 수 있습니다.  계획에 테스트 시스템 사용을 포함 시키십시오.  패치, 커널 및 OS 업데이트, 보안 소프트웨어의 유효성을 검사하기위한 계획된 루틴 및 프로세스를 개발하고, 프로젝트 문서 및 향후 계획을 업데이트 할 때 잊지 말아야합니다.

중복성이 높고 안정성이 높으며 가용성이 높은 시스템을 미리 계획하고 Go-Live 후에 QA / 사전 프로덕션 클러스터를 유지하고 정기적 인 유지 관리 및 업데이트를 계획하는 경우 계획을 유지할 수 있습니다. 데이트 밤 배우자와 함께.  또한 데이트 밤뿐만 아니라 다운 프로덕션 시스템으로 인해 오전 3시 모닝콜을 무료로 유지할 수 있습니다.  배우자를 잘 사랑하기위한 팁입니다.

아내를 사랑하기 때문에 고 가용성 엔터프라이즈 보호 솔루션의 일부로 SIOS Technology Corp.의 DataKeeper Cluster Edition 및 Windows 및 Linux 용 SIOS Protection Suite 제품을 고객이 배포 할 수 있도록 도와줍니다.  SIOS에 문의하십시오.

— Cassius Rhue, 고객 경험 부사장

SIOS의 허가하에 복제 된 기사

 
7월 22, 2020

백업, 복제 및 고 가용성 클러스터링을 결합하는 방법

백업, 복제 및 고 가용성 클러스터링을 결합하는 방법

백업, 복제 및 고 가용성 클러스터링을 결합하는 방법

백업, 복제 및 고 가용성 (HA) 클러스터링은 IT 위험 관리의 기본 요소이며 자동차의 바퀴만큼이나 필수적입니다. IT 데이터 보호에도 복제가 필수적입니다.

백업 및 HA 클러스터 환경은 상호 배타적이지 않습니다

백업, 복제 및 페일 오버가 모두 중요하지만 이들을 올바르게 적용하려면 이해해야 할 주요 차이점이 있습니다.

예를 들어, 더 큰 데이터 보호 환경에서 데이터를 고려하지 않고 복제를 사용하여 지속적으로 최신 데이터 사본을 유지 보수 할 수 있지만, 바이러스에 감염된 데이터와 같은 문제점 데이터도 복사합니다.

이러한 경우 데이터를 마지막으로 알려진 올바른 지점으로 되돌리려면 백업이 필수적입니다. 복제를 수행하면 데이터를 생성하여 eDiscovery 유형 모델에서 지원할 수없는 방식으로 시스템 장애 직전에 복제 된 이미지에 액세스 할 수 있습니다 (= RTO / RTO가 우수함).

따라서 "SIOS Protection Suite"에는 SIOS LifeKeeper 클러스터링 소프트웨어와 DataKeeper 복제 소프트웨어가 모두 포함됩니다. SIOS LifeKeeper는 애플리케이션 상태를 모니터링하고 애플리케이션 페일 오버를 오케스트레이션하는 HA 페일 오버 클러스터 제품이며 DataKeeper는 블록 기반 스토리지 복제 소프트웨어입니다. 그러나 HA 클러스터라고해서 백업이 필요하지 않다는 의미는 아닙니다. SIOS Protection Suite를 사용하여 HA 클러스터 환경에서 백업 할 때주의 사항 및주의 사항을 고려하십시오.

고 가용성 클러스터링 환경에서 5 가지 백업 지점

백업 획득의 대상으로 다음 5 가지 사항을 고려하십시오.

  1. 운영 체제 (OS)
  2. SIOS Protection Suite – LifeKeeper / DataKeeper 프로그램 클러스터링 소프트웨어
  3. SIOS Protection Suite – LifeKeeper / DataKeeper 구성 정보
  4. 응용 프로그램 (예 : SQL Server, SAP S / 4 HANA, Oracle, PostgreSQL 등)
  5. 응용 프로그램 데이터

OS 백업

OS를 백업하려면 표준 OS 유틸리티 또는 타사 백업 소프트웨어를 사용하는 것이 일반적입니다. 그러나 "고 가용성"환경에는 특별한 고려 사항이 없으므로 여기서 다루지 않습니다.

SIOS Protection Suite 클러스터링 소프트웨어 백업

SIOS Protection Suite에는 SIOS LifeKeeper / DataKeeper 프로그램이 포함되어 있습니다. OS 표준 유틸리티 또는 타사 백업 소프트웨어를 사용하여 얻을 수도 있지만 디스크 오류 등으로 인해 프로그램이 사라지는 경우. 의도적으로 백업하지 않고 다시 설치해야합니다. 아마도 이분법에 대해 생각하는 사람들이있을 것입니다.

SIOS Protection Suite 구성 정보 백업

SIOS LifeKeeper에는 구성 정보를 백업 할 수있는 lkbackup이라는 간단한 명령이 제공됩니다. lkbackup은 SIOS LifeKeeper 및 관련 리소스에서 실행될 수 있으며 실행중인 서비스에는 영향을 미치지 않습니다.

이 명령은 다음 세 가지 주요 경우에 실행될 수 있습니다.

  • 새로 생성 된 SIOS LifeKeeper 리소스를 설치 한 직후
  • SIOS LifeKeeper 구성 변경 전후 (종속성 추가 / 변경, 자원 추가 / 삭제)
  • SIOS LifeKeeper 버전 업그레이드 전후

lkbackup으로 구성 정보를 백업하는 경우 디스크 고장으로 인해 구성 정보가 사라지거나 조작 실수 등으로 구성 정보가 손상된 경우에도) 원래의 작동 상태로 빠르게 돌아갈 수 있습니다.

백업 운영 프로그램

운영 프로그램 백업은 HA 클러스터에서 보호되는 비즈니스 응용 프로그램을 백업하는 것을 의미하지만 1에서와 같이 OS 표준 유틸리티 또는 타사 백업 소프트웨어를 사용하여 백업 이미지를 생성 및 복원 할 수 있습니다. 그리고 위의 2.

백업 비즈니스 애플리케이션 데이터

HA 클러스터 환경에서는 활성 및 대기 서버 모두가 액세스 할 수있는 공유 스토리지가 제공됩니다. 정상 작동 중에는 공유 스토리지가 활성 클러스터 노드에서 사용됩니다. 응용 프로그램 데이터 (예 : 데이터베이스 데이터)는 일반적으로이 공유 스토리지의 스토리지이지만이 스토리지를 백업 할 때 다음 사항을 명심해야합니다.

공유 스토리지 구성 

활성 클러스터 노드와 대기 시스템이 공유하는 스토리지로 SANless 클러스터 구성에있는 데이터의 백업을 확보 할 때, 활성 시스템에서만 데이터에 액세스 할 수 있습니다 (대기 시스템은 데이터에 액세스 할 수 없음). 결과적으로 백업도 활성화됩니다. 이 경우 장애 조치 및 백업 복원 시나리오를 처리하기에 충분한 처리 능력이 있는지 확인하십시오.

공유 스토리지 구성

 

데이터 복제 구성 

"데이터 복제"구성의 경우 운영 체제에서의 백업이 기본이지만 미러링을 일시적으로 중지하고 잠금을 해제하면 백업을 대기 시스템 측에서도 실행할 수 있습니다. 그러나이 경우 데이터가 일시적으로 동기화되지 않습니다.

데이터 복제 구성

외부 백업 서버에서 클러스터 노드 백업

외부 백업 서버에서 클러스터 노드 백업을 수행하려면 클러스터 노드의 가상 또는 실제 IP 주소를 사용하십시오. 각 경우에 유의해야 할 사항은 다음과 같습니다.

클러스터 노드의 가상 IP 주소를 사용하여 백업

백업 서버의 관점에서 LifeKeeper의 가상 IP 주소로 표시된 노드로 백업이 실행됩니다. 이 경우 백업 서버는 어떤 노드가 활성 노드인지 알 필요가 없습니다.

클러스터 노드의 가상 IP 주소를 사용하여 백업

클러스터 노드의 실제 IP 주소를 사용하여 백업

백업 서버의 관점에서 LifeKeeper의 가상 IP 주소를 사용하지 않고 실제 IP 주소로 백업이 수행됩니다. 대기 클러스터 노드에서 공유 스토리지에 액세스 할 수 없으므로 백업 서버와 클라이언트는 어떤 노드가 활성 노드인지 확인해야합니다.

잘 테스트되고 검증 된 구성 백업에서 백업, 복제 및 장애 조치 클러스터링을 결합하는 것이 필수적입니다. 사용자 측에서 사전에 충분한 작동 검증을 수행하십시오.

SIOS의 허가하에 재생
  • Results 326-330 of 927
  • < Page 66 of 186 >

  • 우리의 메일 링리스트에 가입하세요