SIOS SANless clusters – 페이지 38

6월 27, 2022	고가용성 클러스터를 위한 새로운 옵션, SIOS, Microsoft Azure 공유 디스크 지원 강화 고가용성 클러스터를 위한 새로운 옵션, SIOS, Microsoft Azure 공유 디스크 지원 강화 마이크로소프트 도입 Azure 공유 디스크 2022년 1분기. 공유 디스크를 사용하면 관리 디스크를 둘 이상의 호스트에 연결할 수 있습니다. 사실상 이는 Azure에 이제 SAN 스토리지와 동등한 기능이 있음을 의미합니다. 고가용성 클라우드에서 공유 디스크를 사용하는 클러스터! SIOS Lifekeeper 클러스터 계층 구조와 함께 Azure 공유 디스크를 사용하는 주요 이점은 더 이상 저장소 쿼럼 또는 감시 노드가 필요하지 않다는 것입니다. 이렇게 하면 소위 말하는 것을 피할 수 있습니다. 분할 뇌 – 노드 간의 통신이 끊어지고 여러 노드가 잠재적으로 동시에 데이터를 변경할 때 발생합니다. 노드 수가 적으면 비용과 복잡성이 줄어듭니다. LifeKeeper SCSI-3 영구 예약(SCSI3) 복구 키트 SIOS는 애플리케이션 복구 키트(ARK) Linux용 LifeKeeper 제품용. 이것을 LifeKeeper SCSI-3 영구 예약(SCSI3) 복구 키트라고 합니다. 이를 통해 Azure Shared Disks를 SCSI-3 예약과 함께 사용할 수 있습니다. ARK는 공유 디스크가 현재 해당 디스크에 SCSI-3 예약을 보유하고 있는 노드에서만 쓸 수 있도록 보장합니다. SIOS Lifekeeper를 설치할 때 설치 프로그램은 Microsoft Azure EC2에서 실행 중임을 감지합니다. Azure Shared Disk에 대한 지원을 활성화하기 위해 LifeKeeper SCSI-3 영구 예약(SCSI3) 복구 키트를 자동으로 설치합니다. Lifekeeper 내에서 리소스 생성은 간단하고 간단합니다(그림 1). Azure Shared Disk는 로컬로 탑재되면 파일 시스템 유형 리소스로 Lifekeeper에 간단히 추가됩니다. Lifekeeper는 ID를 할당하고(그림 2) SCSI-3 잠금을 자동으로 관리합니다. 그림 1. LifeKeeper에서 SAP 인스턴스(sapinst) 생성 그림 2: 두 노드로 확장된 생성됨. SCSI-3 예약은 Azure Shared Disk가 예약을 보유하는 노드에서만 쓰기 가능하도록 보장합니다(그림 3). 클러스터 노드가 서로 통신이 끊기는 시나리오에서 대기 서버가 온라인 상태가 되어 잠재적인 분할 브레인 상황이 발생합니다. 그러나 SCSI-3 예약 때문에 한 번에 하나의 노드만 디스크에 액세스할 수 있습니다. 이것은 실제로 실제 분할 브레인 시나리오를 방지합니다. 하나의 시스템만 예약을 유지합니다. 새로운 활성 노드가 되거나(이 경우 다른 노드가 재부팅됨) 활성 노드로 유지됩니다. Azure Shared Disk 예약을 보유하지 않는 노드는 단순히 "대기 상태" 상태의 리소스로 끝납니다. 단순히 예약을 획득할 수 없기 때문입니다. 그림 3 – 이미 예약된 디스크를 마운트하려고 할 때 Lifekeeper 로그의 출력. Azure 공유 디스크에 대한 Microsoft의 정의 링크 https://docs.microsoft.com/en-us/azure/virtual-machines/disks-shared 기대할 수 있는 것 현재 SIOS는 LRS(Locally-redundant Storage)를 지원합니다.ZRS(영역 중복 저장소)를 테스트하고 지원하기 위해 Microsoft와 협력하고 있습니다. 이상적으로는 리소스 계층 구조를 활성 스토리지의 가장 로컬 노드로 장애 조치할 수 있도록 ZRS 오류가 있는 시점을 알고 싶습니다. SIOS는 Azure 공유 디스크 지원이 Linux용 Lifekeeper 9.6.2의 다음 릴리스에 제공될 것으로 기대하고 있습니다. 의 허가를 받아 재생산 시오스
6월 23, 2022	스플릿 브레인(Split Brain)이란 무엇이며 이를 피하는 방법 스플릿 브레인(Split Brain)이란 무엇이며 이를 피하는 방법 우리가 논의한 바와 같이, 고가용성 클러스터 환경에는 하나의 활성 노드와 활성 노드가 실패하거나 응답을 중지할 때 서비스를 인계할 하나 이상의 대기 노드가 있습니다. 이것은 노드 간의 네트워크 계층을 고려할 때까지 합리적인 가정처럼 들립니다. 노드 간의 네트워크 경로가 다운되면 어떻게 됩니까? 이제 어느 노드도 다른 노드와 통신할 수 없으며 이 상황에서 대기 서버는 활성 노드가 실패했다고 생각하는 것을 기반으로 스스로를 활성 서버로 승격할 수 있습니다. 이로 인해 두 노드가 모두 '활성' 상태가 되어 서로가 다른 노드를 죽은 것으로 간주하게 됩니다. 결과적으로 두 노드의 데이터가 변경됨에 따라 데이터 무결성과 일관성이 손상됩니다. 이것은 "스플릿 브레인" . 스플릿 브레인 시나리오를 피하려면 클러스터 내에 쿼럼 노드('증인'이라고도 함)를 설치해야 합니다. 쿼럼 노드를 추가하면(짝수 수의 노드로 구성된 클러스터에) 홀수 수의 노드(3, 5, 7 등)가 생성되며 노드는 클러스터 내에서 활성 노드로 작동해야 하는 노드를 결정하기 위해 투표합니다. 아래 예에서는 노드 B가 포함된 서버 랙이 손실되었습니다. 랜 연결성. 이 시나리오에서 클러스터 환경에 세 번째 노드를 추가하면 시스템은 여전히 활성 노드가 되어야 하는 노드를 결정할 수 있습니다. 쿼럼/감시 기능은 시오스 보호 스위트. 설치 시 Quorum/Witness는 모든 노드(쿼럼 노드 뿐만 아니라)에서 선택되고 모든 노드(쿼럼 노드 포함) 간에 통신 경로가 정의됩니다. 쿼럼 노드는 활성 서비스를 호스팅하지 않습니다. 유일한 역할은 노드 통신에 참여하여 활성 상태를 결정하고 통신 중단 시 '동률 투표'를 제공하는 것입니다. 시오스 또한 지원 IO 펜싱 및 스토리지 쿼럼 장치로 사용되며 이러한 구성에서는 추가 쿼럼 노드가 필요하지 않습니다. 의 허가를 받아 재생산 시오스
6월 19, 2022	노드 간 데이터 복제는 어떻게 작동합니까? 노드 간 데이터 복제는 어떻게 작동합니까? 기존 데이터 센터 시나리오에서 데이터는 일반적으로 SAN(Storage Area Network)에 저장됩니다. SAN ). 클라우드 환경은 일반적으로 공유 스토리지를 지원하지 않습니다. 시오스 DataKeeper는 복제 기술을 사용하여 현재 활성 데이터의 복사본을 만드는 '공유' 스토리지를 제공합니다. RAID1 장치(장치 간에 미러링된 데이터)로 작동하는 NetRAID 장치를 생성합니다. 데이터 변경 사항은 미러 소스(활성 노드의 디스크 장치 – 아래 다이어그램의 노드 A)에서 미러 대상(대기 노드의 디스크 장치 – 아래 다이어그램의 노드 B)으로 복제됩니다. 두 장치의 데이터 일관성을 보장하기 위해 활성 노드만 복제된 장치에 대한 쓰기 액세스 권한을 갖습니다(아래 예의 /datakeeper 마운트 지점). 복제된 장치(/datakeeper 마운트 지점)에 대한 액세스는 미러 대상(예: 대기 노드)인 동안 허용되지 않습니다. 의 허가를 받아 재생산 시오스
6월 15, 2022	클라이언트가 활성 노드에 연결하는 방법 클라이언트가 활성 노드에 연결하는 방법 앞서 논의한 바와 같이 한 번 고가용성 클러스터 두 개 이상의 노드가 동시에 실행되고 사용자가 "활성" 노드 . 활성 노드에서 문제가 발생하면 "장애 조치" 조건이 발생하고 "대기" 노드가 새로운 "활성" 노드가 됩니다. 장애 조치가 발생하면 클라이언트가 장애 조치 조건을 감지하고 다시 연결하거나 사용자의 활성 클라이언트 세션을 활성 노드로 원활하게 전송할 수 있는 메커니즘이 있어야 합니다. 가상 IP 주소 일반적으로 클러스터가 구성되고 클라이언트가 클라이언트와 통신할 때 "가상" IP 주소가 생성됩니다. 활성 노드 가상 IP 주소를 사용합니다. 장애 조치가 발생하면 가상 IP 주소가 새 활성 노드에 재할당되고 클라이언트가 동일한 가상 IP 주소에 다시 연결합니다. 예를 들어 IP 주소가 다음과 같은 두 개의 노드 A와 B가 있다고 가정합니다. 10.20.1.10 그리고 10.20.2.10 . 이 예에서는 현재 활성 노드에 할당된 것으로 간주되어야 하는 10.20.0.10의 가상 IP 주소를 정의합니다. 이는 한 노드의 한 네트워크 인터페이스 카드에 두 번째 IP 주소를 할당하는 것과 유사합니다. 만약 명령이 아이피 활성 노드에 입력하면 두 IP 주소가 모두 나타납니다(이 Linux 예의 10행과 12행). 그만큼 ARP 규약 클라이언트가 IP 주소를 사용하여 서버를 찾으려고 할 때 클라이언트는 일반적으로 다음을 사용합니다. ARP (주소 확인 프로토콜)을 찾기 위해 맥 (미디어 액세스 제어) 대상 시스템의 주소입니다. 클라이언트가 대상 IP 주소를 찾기 위해 메시지를 브로드캐스트하면 활성 노드는 다음으로 응답합니다. 맥 주소와 클라이언트가 요청을 해결하고 연결합니다. ARP 클라우드 환경을 위한 대안 그러나 클라우드 환경에서는 다음을 사용하여 활성 노드를 식별할 수 없습니다. ARP 가상 환경에서 많은 레이어가 추상화됩니다. 특정 클라우드 환경에서 사용 중인 네트워크 인프라에 기반한 대체 방법이 필요할 수 있습니다. 일반적으로 여러 옵션이 있으며 다음 목록에서 선택해야 합니다. AWS 라우팅 테이블 시나리오 AWS 탄력적 IP 시나리오 AWS Route53 시나리오 Azure 내부 부하 분산 장치 시나리오 Google Cloud 내부 부하 분산기 시나리오 의 허가를 받아 재생산 시오스
6월 11, 2022	퍼블릭 클라우드 플랫폼과 네트워크 구조의 차이점 퍼블릭 클라우드 플랫폼과 네트워크 구조의 차이점 여러 가지가 있습니다 퍼블릭 클라우드 플랫폼 Amazon Web Services( AWS ), 마이크로소프트 애저 및 구글 클라우드. 인프라에는 많은 유사점이 있지만 몇 가지 차이점이 있습니다. 많은 경우에 VPC (가상 사설 클라우드) 또는 VNET 지역에 묶인 (가상 네트워크)가 생성됩니다. 하나 이상 VPC s는 애플리케이션의 논리적 그룹에 대해 정의될 수 있습니다. 이렇게 함으로써 서로 다른 시스템은 서로 다른 경우가 아니면 별도의 연결되지 않은 네트워크로 나뉩니다. VPC s는 구체적으로 연결됩니다. 아래에서 VPC 다양한 서브넷을 정의할 수 있습니다. 목적에 따라 일부 서브넷은 인터넷에 액세스할 수 있는 "퍼블릭" 서브넷으로 구성되고 일부는 인터넷에 액세스할 수 없는 "비공개" 서브넷으로 구성됩니다. 일부 클라우드 공급자(예: Azure 및 Google Cloud)에서는 서브넷을 가용 영역(다른 데이터 센터)에 걸쳐 정의할 수 있지만 일부(예: AWS ) 가용 영역에서 서브넷을 정의할 수 없습니다. 후자의 경우 각 가용 영역에 대해 서브넷을 정의해야 합니다. 이 가이드에서는 각 노드에 대해 서로 다른 가용 영역을 사용합니다. 일단 기본적인 기능은 시오스 제품이 이해되면 여러 서브넷에 워크로드를 분산하고 이러한 서브넷의 IP 범위를 수정하고 네트워크가 인터넷 등 의 허가를 받아 재생산 시오스