재해 복원력이 뛰어난 클라우드: 작동 방식

헤이 하브르!

설 연휴 이후 XNUMX개 사이트를 기반으로 재해 방지 클라우드를 다시 출시했습니다. 오늘 우리는 그것이 어떻게 작동하는지 설명하고 클러스터의 개별 요소가 실패하고 전체 사이트가 충돌할 때 클라이언트 가상 머신에 어떤 일이 일어나는지 보여줄 것입니다(스포일러 – 모든 것이 정상입니다).

OST 사이트의 재해 방지 클라우드 스토리지 시스템.

내부 뭐니 뭐니?

내부적으로 클러스터에는 VMware ESXi 하이퍼바이저가 포함된 Cisco UCS 서버, 2240개의 INFINIDAT InfiniBox FXNUMX 스토리지 시스템, Cisco Nexus 네트워크 장비 및 Brocade SAN 스위치가 있습니다. 클러스터는 OST와 NORD의 두 사이트로 나뉩니다. 즉, 각 데이터 센터에는 동일한 장비 세트가 있습니다. 실제로 이것이 재난에 강한 이유입니다.

한 사이트 내에서는 주요 요소(호스트, SAN 스위치, 네트워킹)도 복제됩니다.
두 사이트는 역시 예약된 전용 광섬유 경로로 연결되어 있습니다.

스토리지 시스템에 대한 몇 마디. 우리는 NetApp에 ​​재해 방지 클라우드의 첫 번째 버전을 구축했습니다. 여기에서 우리는 INFINIDAT를 선택했으며 그 이유는 다음과 같습니다.

• 액티브-액티브 복제 옵션. 이를 통해 스토리지 시스템 중 하나에 완전히 장애가 발생하더라도 가상 머신이 계속 작동할 수 있습니다. 복제에 대해서는 나중에 자세히 설명하겠습니다.
• 시스템 내결함성을 높이기 위한 XNUMX개의 디스크 컨트롤러. 보통 XNUMX개가 있습니다.
• 준비된 솔루션. 우리는 네트워크에 연결하고 구성하기만 하면 되는 사전 조립된 랙을 받았습니다.
• 세심한 기술 지원. INFINIDAT 엔지니어는 스토리지 시스템 로그와 이벤트를 지속적으로 분석하고, 새로운 펌웨어 버전을 설치하고, 구성을 지원합니다.

포장을 풀고 찍은 사진은 다음과 같습니다.

원리

클라우드는 이미 자체적으로 내결함성을 갖추고 있습니다. 단일 하드웨어 및 소프트웨어 오류로부터 클라이언트를 보호합니다. 재해 방지 기능은 한 사이트 내에서 발생하는 대규모 오류(예: 스토리지 시스템 오류(또는 자주 발생하는 SDS 클러스터 🙂), 스토리지 네트워크의 대규모 오류 등)로부터 보호하는 데 도움이 됩니다. 음, 가장 중요한 것은 화재, 정전, 침입자 탈취 또는 외계인 착륙으로 인해 전체 사이트에 액세스할 수 없는 경우 이러한 클라우드를 사용하면 비용을 절약할 수 있다는 것입니다.

이러한 모든 경우에 클라이언트 가상 머신은 계속 작동하며 그 이유는 다음과 같습니다.

클러스터 설계는 클라이언트 가상 머신이 있는 모든 ESXi 호스트가 두 스토리지 시스템 중 하나에 액세스할 수 있도록 설계되었습니다. OST 사이트의 스토리지 시스템에 장애가 발생하더라도 가상 머신은 계속 작동합니다. 가상 머신이 실행 중인 호스트는 데이터를 얻기 위해 NORD의 스토리지 시스템에 액세스합니다.

클러스터의 연결 다이어그램은 다음과 같습니다.

이는 두 사이트의 SAN 패브릭 사이에 스위치 간 링크가 구성되어 있기 때문에 가능합니다. 패브릭 A OST SAN 스위치는 패브릭 A NORD SAN 스위치에 연결되고 패브릭 B SAN 스위치에도 유사하게 연결됩니다.

SAN 공장의 이러한 모든 복잡성이 이해되도록 두 스토리지 시스템 간에 Active-Active 복제가 구성됩니다. 정보는 로컬 및 원격 스토리지 시스템에 거의 동시에 기록되며 RPO = 0입니다. 원본 데이터는 한 스토리지 시스템에 저장되고 해당 복제본은 다른 스토리지 시스템에 저장되는 것으로 나타났습니다. 데이터는 스토리지 볼륨 수준에서 복제되고 VM 데이터(디스크, 구성 파일, 스왑 파일 등)가 여기에 저장됩니다.

ESXi 호스트는 기본 볼륨과 해당 복제본을 하나의 디스크 디바이스(스토리지 디바이스)로 간주합니다. ESXi 호스트에서 각 디스크 디바이스까지 24개의 경로가 있습니다.

12개의 경로는 이를 로컬 스토리지 시스템(최적 경로)에 연결하고 나머지 12개는 원격 스토리지 시스템(비최적 경로)에 연결합니다. 일반적인 상황에서 ESXi는 "최적" 경로를 사용하여 로컬 스토리지 시스템의 데이터에 액세스합니다. 이 스토리지 시스템에 장애가 발생하면 ESXi는 최적의 경로를 잃고 "최적이 아닌" 경로로 전환됩니다. 이것이 다이어그램에서 보이는 모습입니다.

재해 방지 클러스터 계획.

모든 클라이언트 네트워크는 공통 네트워크 패브릭을 통해 두 사이트 모두에 연결됩니다. 각 사이트는 클라이언트 네트워크가 종료되는 PE(Provider Edge)를 실행합니다. PE는 공통 클러스터로 통합됩니다. PE가 한 사이트에서 실패하면 모든 트래픽이 두 번째 사이트로 리디렉션됩니다. 덕분에 PE가 없는 사이트의 가상 머신은 네트워크를 통해 클라이언트에 계속 액세스할 수 있습니다.

이제 다양한 오류가 발생하는 동안 클라이언트 가상 머신에 어떤 일이 발생하는지 살펴보겠습니다. 가장 가벼운 옵션부터 시작하여 가장 심각한 전체 사이트 오류로 끝내겠습니다. 예제에서 기본 플랫폼은 OST이고, 데이터 복제본이 있는 백업 플랫폼은 NORD입니다.

다음과 같은 경우 클라이언트 가상 머신은 어떻게 되나요?

복제 링크가 실패했습니다. 두 사이트의 스토리지 시스템 간 복제가 중지됩니다.
ESXi는 (최적 경로를 통해) 로컬 디스크 장치에서만 작동합니다.
가상 머신은 계속 작동합니다.

ISL(스위치 간 링크)이 끊어졌습니다. 그럴 가능성은 거의 없습니다. 일부 미친 굴착기가 한 번에 여러 개의 광학 경로를 파헤치지 않는 한, 이는 독립적인 경로에서 실행되고 다른 입력을 통해 현장으로 이동됩니다. 하지만 어쨌든. 이 경우 ESXi 호스트는 경로의 절반을 잃고 로컬 스토리지 시스템에만 액세스할 수 있습니다. 복제본이 수집되지만 호스트는 복제본에 액세스할 수 없습니다.

가상 머신이 정상적으로 작동하고 있습니다.

사이트 중 하나에서 SAN 스위치에 오류가 발생했습니다. ESXi 호스트는 스토리지 시스템에 대한 일부 경로를 잃습니다. 이 경우 스위치가 실패한 사이트의 호스트는 해당 HBA 중 하나를 통해서만 작동합니다.

가상 머신은 계속해서 정상적으로 작동합니다.

사이트 중 하나의 모든 SAN 스위치가 실패합니다. OST 사이트에서 이런 재난이 일어났다고 가정해 보겠습니다. 이 경우 이 사이트의 ESXi 호스트는 디스크 디바이스에 대한 모든 경로를 잃게 됩니다. 표준 VMware vSphere HA 메커니즘이 작동합니다. 최대 140초 내에 NORD에 있는 OST 사이트의 모든 가상 머신을 다시 시작합니다.

NORD 사이트 호스트에서 실행되는 가상 머신이 정상적으로 작동하고 있습니다.

ESXi 호스트가 한 사이트에서 실패합니다. 여기서 vSphere HA 메커니즘이 다시 작동합니다. 장애가 발생한 호스트의 가상 머신이 동일한 사이트 또는 원격 사이트의 다른 호스트에서 다시 시작됩니다. 가상 머신 다시 시작 시간은 최대 1분입니다.

OST 사이트의 모든 ESXi 호스트가 실패하면 옵션이 없습니다. VM이 다른 호스트에서 다시 시작됩니다. 재시작 시간은 동일합니다.

한 사이트에서 스토리지 시스템에 오류가 발생했습니다. OST 사이트에서 스토리지 시스템에 오류가 발생했다고 가정해 보겠습니다. 그런 다음 OST 사이트의 ESXi 호스트는 NORD의 스토리지 복제본 작업으로 전환됩니다. 장애가 발생한 스토리지 시스템이 다시 서비스되면 강제 복제가 발생하고 ESXi OST 호스트가 다시 로컬 스토리지 시스템에 액세스하기 시작합니다.

가상머신은 그동안 정상적으로 작동해왔습니다.

사이트 중 하나에 오류가 발생했습니다. 이 경우 모든 가상 머신은 vSphere HA 메커니즘을 통해 백업 사이트에서 다시 시작됩니다. VM 다시 시작 시간은 140초입니다. 이 경우 가상 머신의 모든 네트워크 설정이 저장되며 클라이언트는 네트워크를 통해 계속 액세스할 수 있습니다.

백업 사이트에서 머신을 원활하게 다시 시작할 수 있도록 각 사이트는 절반만 채워져 있습니다. 후반부는 모든 가상 머신이 손상된 두 번째 사이트에서 이동할 경우를 대비한 예비 공간입니다.

두 개의 데이터 센터를 기반으로 한 재해 방지 클라우드는 이러한 장애로부터 보호합니다.

주요 자원 외에도 두 번째 사이트에 예비비가 필요하기 때문에 이러한 즐거움은 저렴하지 않습니다. 따라서 비즈니스에 중요한 서비스는 장기간의 다운타임으로 인해 막대한 재정적 손실과 평판 손실이 발생하거나 정보 시스템이 규제 기관이나 회사 내부 규정의 재해 복구 요구 사항을 따르는 클라우드에 배치됩니다.

출처 :

1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides

출처 : habr.com