SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 제작품
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 뉴스 및 이벤트
  • 서버 클러스터 단순화
  • 성공 사례
  • 저희에 게 연락
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

왜 오늘 # 관리 클러스터를 관리 디스크로 변환해야합니까!

8월 9, 2017 by Jason Aw Leave a Comment

3 월 16 일에 미국 동부 지역의 일부 인스턴스에 영향을 미친 최근 스토리지 중단에 대해 들었을 수 있습니다. 작동 중단의 근본 원인 분석이 여기에 게시됩니다.

3 월 16 일 미국 동부 정전 사태

고객에게 미치는 영향 : 동부 미국 지역의 스토리지를 사용하는 고객 중 일부가 하나의 스토리지 단위로 스토리지 계정에 액세스하는 동안 오류 및 시간 초과를 경험했을 수 있습니다.

"단일 스토리지 저울 단위 란 무엇입니까?" 글쎄, 당신은 하나의 스토리지 클러스터, 또는 하나의 SAN으로 생각할 수도 있지만, 그것에 대해 생각하고 싶을 수도 있습니다. Azure가 정확한 인프라를 게시하지는 않는다고 생각하지만, 뒷장에서 백엔드 스토리지 용 스케일 아웃 파일 서버를 사용하고 있다고 가정 할 수 있습니다.

그래서 문제는 어떻게 최소한의 중단 시간으로이 정전에서 살아남을 수 있습니까? 근본 원인 분석을 자세히 읽으면이 작은 너겟을 발견하게됩니다.

가용성 세트에서 관리 디스크를 사용하는 가상 시스템은이 문제 발생시 가용성을 유지합니다.

당신이 요구하는 관리 디스크는 무엇입니까? 음, 2 월 8 일 Corey Sanders는 Managed Disks의 GA를 발표했습니다. 여기서 Managed Disks에 대한 모든 정보를 읽을 수 있습니다. https://azure.microsoft.com/en-us/services/managed-disks/

Managed Disks가 이러한 장애를 일으키는 데 도움이되는 이유는 Managed Disks와 결합 된 가용성 세트를 활용함으로써 가용성 세트의 각 인스턴스가 서로 다른 "스토리지 저울 단위"에 연결되도록 보장하기 때문입니다. 따라서이 경우 클러스터 노드 중 하나만 실패하고 나머지 노드는 작업 부하를 인계받습니다.

Managed Disks가 사용 가능하기 전에 (2016 년 2 월 8 일 이전에 배포 된 모든 것), 서버에 연결된 스토리지가 다른 스토리지 스케일 단위에 있는지 확인하는 방법이 없었습니다. 물론 각 인스턴스에 대해 서로 다른 저장소 계정을 사용할 수는 있지만 사실상 이러한 저장소 계정이 다른 저장소 규모 단위로 저장소를 제공한다는 보장은 없습니다.

따라서 Availability Set이 인스턴스 자체의 가용성을 보장하기 위해 다른 Fault Domains 및 Update Domains에있는 것을 보장하지만 각 인스턴스에 연결된 추가 스토리지는 실제로 단일 실패 지점을 나타냅니다. 스토리지 자체는 복원력이 뛰어나지 만 3 개의 데이터 복사본과 지리적 중복 옵션을 사용할 수 있습니다.이 경우 정전이 발생하면 전체 스토리지 스케일 장치가 연결된 모든 서버와 함께 중단됩니다.

짧은 이야기 만하면됩니다. 중단 시간 최소화를 위해 가능한 한 빨리 Managed Disk로 마이그레이션하십시오.

https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to-managed-disks

다운 타임을 최소화하고 싶다면 클라우드 제공자 또는 온 – 프레미엄 클라우드에 걸쳐있는 하이브리드 클라우드 배치를 고려해야합니다!

Filed Under: 서버 클러스터 단순화

ARM을 사용 하 여 Azure에서 2 노드 파일 서버 장애 조치 클러스터 배포

7월 19, 2017 by Jason Aw Leave a Comment

ARM을 사용 하 여 Azure에서 2 노드 파일 서버 장애 조치 클러스터 배포

이 게시물에서 우리는 Azure 리소스 관리자를 사용 하 여 Azure의 단일 지역에서 2 노드 파일 서버 장애 조치 클러스터를 배포 하는 데 필요한 특정 단계를 상세하게 됩니다. 난 당신과 기본 장애 조치 클러스터 개념으로 기본 푸른 개념에 익숙한 것 이다 초점 Azure에 있는 파일 서버 장애 조치 클러스터 배포에 대 한 고유의에이 문서를 가정 합니다.

DataKeeper 클러스터 에디션 로컬로 연결 된 저장소, 프리미엄 또는 표준 디스크 하 고 동기적으로, 비동기적으로 디스크를 복제 하는 여부 또는 혼합 또는 둘 다, 두 개 이상의 클러스터 노드 사이 걸릴 수 있습니다. 또한, DataKeeper 볼륨 리소스 Windows 서버 장애 조치 클러스터링 실제 디스크 리소스의 장소를가지고는에 등록 된다. 실제 디스크 리소스와 같은 SCSI-3 예약 제어, 대신 DataKeeper 볼륨 활성 노드는 항상 거울의 소스 보장 미러 방향을 제어 합니다. 늘어나는 만큼 우려는 장애 조치 클러스터링, 느낌 및 실제 디스크 같은 냄새 하며 실제 디스크 리소스는 사용 될 것 이라고 같은 방식으로 사용 됩니다.

필수 조건

  • 당신은 전에 Azure 포털을 이용 했 고 편안 Azure IaaS에서 가상 컴퓨터를 배포.
  • 라이센스 또는 SIOS DataKeeper의 eval 라이센스 취득

Azure Portal을 사용 하 여 파일 서버 장애 조치 클러스터 인스턴스 배포

Azure에서 2 노드 파일 서버 장애 조치 클러스터 인스턴스를 구축, 당신은 기본 가정 가상 네트워크 기반 Azure 리소스 관리자에 있고 하나 이상의 가상 컴퓨터를 하 고 실행 중인 도메인 컨트롤러로 구성 된 것입니다. 일단 가상 네트워크 및 도메인 구성, 우리의 클러스터의 두 노드 역할 것입니다 두 개의 새로운 가상 컴퓨터를 제공 하려고 합니다.

속은 다음과 같이 됩니다.

D c 1-우리의 도메인 컨트롤러와 파일 공유 감시
S q l 1와 SQL2-우리의 파일 서버 클러스터의 두 노드

두 클러스터 노드 프로비저닝 (SQL1 및 SQL2)

Azure 포털을 사용 하 여, 우리는 프로 비전 s q l 1와 SQL2 정확히 같은 방식으로. 인스턴스 크기, 스토리지 옵션, 기타 등등을 포함 하 여 선택할 수 있는 수많은 옵션이 있다. 이 가이드는 몇 가지 정말 좋은 자원 그리고 더 매일 출판 Azure에 서버를 배포 하는 완전 한 가이드를 아닙니다. 그러나 클러스터 된 환경에서 특히, 인스턴스를 만들 때 염두에 두어야 하는 몇 가지 중요 한 것이 있다.

가용성 세트-s q l 1, SQL2 및 d c 1 같은 가용성 세트에 있는 중요 하다. 동일한 여부 설정에 넣어 우리 각 클러스터 노드 및 파일 공유 감시 업데이트 도메인 및 다른 오류 도메인에 있는 보장 됩니다. 이 계획 된 유지 관리 및 클러스터 쿼럼을 유지 관리 하 고 가동 중단을 피할 수 있게 계속 됩니다 계획 되지 않은 유지 관리 동안 보장 하는 데 도움이 됩니다.

3
그림 3-클러스터 노드 및 파일 공유 감시 같은 가용성 설정에 추가 해야 합니다.

정적 IP 주소

일단 각 VM을 제공 하는 설정으로가 서 하 고 IP 주소는 정적 설정을 변경 원할 것입니다. 우리는 변화를 우리의 클러스터 노드의 IP 주소를 원하지 않습니다.

4
그림 4-확인 각 클러스터 노드를 사용 하 여 정적 IP

스토리지

마찬가지로 지금까지 스토리지에 관한 성능 유용한 SQL Server Azure 가상 컴퓨터에 대 한 상담을 원할 것입니다. 어떤 경우에, 당신은 최소한 각 클러스터 노드를 하나 이상 추가 디스크를 추가 해야 합니다. DataKeeper 기본 디스크, 프리미엄 스토리지 또는 심지어 저장소 풀의 여러 디스크를 저장소 풀에 구성 된 사용할 수 있습니다. 그냥 각 클러스터 노드에 동일한 양의 스토리지를 추가 하 고 동일 하 게 구성 해야 합니다. 또한, 각 가상 컴퓨터에 대 한 다른 저장소 계정을 사용 하 여 그 하나의 스토리지 계정에 문제가 영향을 주지 않습니다 두 가상 컴퓨터를 동시에 확인 해야 합니다.

5
그림 5-각 클러스터 노드에 추가 스토리지를 추가할 수 있는지 확인

클러스터 만들기

두 클러스터 노드 (s q l 1와 SQL2) 위에서 설명한 대로 구축 되 고 기존 도메인에 추가 했다고 가정 하면, 우리는 클러스터를 만들 준비가 되어 있다. 우리는 클러스터를 생성 하기 전에 설정 해야 하는 몇 가지 기능이 있습니다. 이러한 기능에는.Net Framework 3.5 및 장애 조치 클러스터링. 이러한 기능은 두 클러스터 노드에서 활성화 될 필요가 있다. 또한 파일 서버 역할을 설정 해야 합니다.

6
그림 6-활성화 모두.Net Framework 3.5 및 장애 조치 클러스터링 기능 및 둘 다에 파일 서버 클러스터 노드

그 역할 및 기능을 사용 하는 일단 클러스터를 만들 준비가 되었습니다. PowerShell와 GUI를 통해 내가 모두 수행할 수 있습니다 보여 단계의 대부분. 그러나, 나는이 매우 첫 번째 단계에 대 한 PowerShell을 사용 하면 클러스터를 만드는 것이 좋습니다 거 야. 장애 조치 클러스터 관리자 GUI를 사용 하 여 클러스터를 만들려고 하면 중복 IP 주소 문제를 되 고 클러스터와 바람 찾을 수 있습니다.

훌륭한 세부 사항에 들어 갔 없이, Azure Vm DHCP를 사용 하는 발견할 것 이다. 우리 푸른 포털에서 VM을 만들 때 "고정 IP"를 지정 하 여 우리 모두는 일종의 DHCP 예약을 만들 했다. 그것은 정확히 DHCP 예약 때문에 진정한 DHCP 예약 DHCP 풀에서 IP 주소를 제거할 것입니다. 대신, 의미 단순히이 푸른 포털에서 정적 ip 주소를 지정 하는 VM에서 요청 하는 경우 IP 주소를 사용할 수 있는 경우 Azure 발행할 것 이다 IP 그것에. 그러나, VM 오프 라인 이며 또 다른 호스트는 같은 서브넷에 온라인 상태가 경우 그것은 잘 수 발행 동일한 IP 주소.

Azure는 DHCP를 구현 하는 방법에 또 다른 이상한 부작용이 있다. (그들은 하는) DHCP를 사용 하 여 호스트 때 Windows 서버 장애 조치 클러스터 GUI와 함께 클러스터를 만들 때 클러스터 IP 주소를 지정 하려면 옵션 하지 않습니다. 대신 그것은 DHCP 주소를 사용 합니다. 이상한 것은, DHCP 중복 IP 주소를 새 IP 주소를 요청 하는 호스트 일반적으로 동일한 IP 주소를 발급 합니다. 클러스터는 일반적으로 완료, 하지만 몇 가지 이상한 오류가 있을 수 있습니다 그리고 실행 하 그것을 얻기 위하여 다른 노드에서 Windows 서버 장애 조치 클러스터 GUI를 실행 해야 할 수 있습니다. 일단 현재 네트워크에서 사용 되지 않은 주소를 클러스터 IP 주소를 변경 하려면 실행 얻을.

단순히 Powershell 통해 클러스터를 만들고 클러스터를 만드는 PowerShell 명령의 일부로 클러스터 IP 주소를 지정 하는 모든 혼란을 피할 수 있습니다.

다음과 같이 새 클러스터 명령을 사용 하 여 클러스터를 만들 수 있습니다.

새로운 클러스터-이름 cluster1-노드 s q l 1, 10.0.0.101 sql2-StaticAddress-NoStorage

클러스터 생성이 완료 된 후 다음 명령을 실행 하 여 클러스터 유효성 검사를 실행 하려면 것입니다.

테스트-클러스터

7
그림 7-클러스터 만들기 및 클러스터 유효성 검사 명령 출력

파일 공유 감시 만들기

아무 공유 저장소가 있기 때문에, 두 개의 클러스터 노드 같은 가용성 설정 다른 서버에 파일 공유 감시를 만들 해야 합니다. 동일한 가용성 세트에 그것을 넣어 그만 손실 1 개의 투표를 쿼럼에서 어떤 주어진된 시간에 수 있습니다. 당신이 확실 하지 않은 경우 파일 공유 감시를 만드는 방법을이 문서 http://www.howtonetworking.com/server/cluster12.htm를 검토할 수 있습니다. 내 데모에서 나 도메인 컨트롤러에서 파일 공유 감시를 넣어. 내가 https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-in-windows-server-2012-r2/에서 클러스터 쿼럼의 철저 한 설명을 게시합니다

데이터 키퍼 설치

클러스터 그것을 만든 후 DataKeeper를 설치 하는 시간이 이다. 그것은 사용자 정의 클러스터 리소스 종류는 클러스터로 등록 될 수 있다 그래서 초기 클러스터를 만든 후 DataKeeper를 설치 하는 것이 중요. 클러스터를 생성 하기 전에 DataKeeper를 설치 하는 경우 설치를 다시 실행 하 고 복구 설치를 간단 하 게 해야 합니다.

8
그림 8-설치 DataKeeper 클러스터를 만든 후

설치 하는 동안 모든 기본 옵션을 수행할 수 있습니다.  사용 하는 서비스 계정이 도메인 계정 이어야 하 고 클러스터의 각 노드에서 로컬 관리자 그룹에 있을 해야 합니다.

9
그림 9-서비스 계정이 각 노드의 로컬 관리자 그룹에 있는 도메인 계정 이어야 합니다.

일단 DataKeeper를 설치 하 고 각 노드에 라이센스 서버를 재 부 팅 해야 합니다.

datakeeper 볼륨 리소스 만들기

DataKeeper 볼륨 리소스를 만들려면 DataKeeper UI를 시작 하 여 두 서버에 연결 해야.
10S q l 1에 연결
11

SQL2에 연결
12

각 서버에 연결 되어, 일단 DataKeeper 볼륨을 만들 준비가 되었습니다. 작업을 마우스 오른쪽 단추로 클릭 하 고 "작업 만들기"를 선택
13

이름 및 설명 작업을 제공 합니다.
14

원본 서버, IP와 볼륨을 선택 합니다. IP 주소는 복제 트래픽을 여행 여부.
15-파일 서버 장애 조치 클러스터

대상 서버를 선택 합니다.
16

옵션을 선택 합니다. 두 Vm 같은 지역에 있는 우리의 목적을 위해 우리 동기 복제를 선택 합니다. 더 긴 거리 복제에 대 한 몇 가지 압축을 사용 하 고 비동기 사용을 원할 것입니다.
17

마지막 팝업에서 예를 클릭 하 여 장애 조치 클러스터링에서 사용 가능한 저장소에 새로운 DataKeeper 볼륨 리소스를 등록 합니다.
18

새로운 DataKeeper 볼륨 리소스 사용 가능한 저장소에 표시 됩니다.
19

파일 서버 클러스터 리소스 만들기

파일 서버 클러스터 리소스를 만들려면 장애 조치 (Failover) 클러스터 인터페이스가 아닌 Powershell을 다시 한 번 사용 합니다. 이는 가상 머신이 DHCP를 사용 하도록 구성 된 경우 GUI 기반 마법사가 클러스터 IP 주소를 입력 하 라는 메시지를 표시 하지 않습니다. 대신, 중복 된 IP 주소를 발급 합니다. 이를 방지 하기 위해 간단한 powershell 명령을 사용 하 여 파일 서버 클러스터 리소스를 만들고 IP 주소를 지정 합니다.

추가-ClusterFileServerRole-저장 "DataKeeper 볼륨 E"-FS2-StaticAddress 10.0.0.201 이름

여기에 지정 하는 IP 주소를 적어 둡니다. 그것은 당신의 네트워크에 고유 IP 주소 여야 합니다. 우리가 우리가 우리의 내부 부하 분산 장치를 만들 때 나중에이 동일한 IP 주소를 사용 합니다.

내부 부하 분산 장치 만들기

여기에 장애 조치 클러스터링 Azure에는 다른 전통적인 인프라입니다. 클라이언트가 클러스터 IP 주소에 직접 연결할 수 없습니다 그래서 푸른 네트워크 스택 무상 ARP를 지원 하지 않습니다. 대신, 클라이언트는 내부 부하 분산 장치에 연결 하 고 활성 클러스터 노드로 리디렉션됩니다. 우리가 필요가 있는 무엇을 할는 내부 부하 분산 장치를 만듭니다. 이 모든 할 수 있습니다 아래와 같이 Azure 포털을 통해.

첫째, 새로운 부하 분산 장치를 만들
30

클라이언트가 공용 인터넷을 통해 연결 하는 경우 공용 부하 분산 장치를 사용할 수 있습니다. 그러나 클라이언트가 동일한 vNet에 상주 한다고 가정할 경우 내부 부하 분산 장치를 만듭니다. 여기서 주의 깊게 살펴 중요 한 점은 가상 네트워크는 클러스터 노드를 있는 네트워크와 동일. 또한, 개인 IP 주소 지정 하는 것입니다 정확 하 게 SQL 클러스터 리소스를 만드는 데 사용 하는 주소와 같습니다.
31

내부 부하 분산 장치 (ILB)를 만든 후 편집 해야 합니다. 우리가 할 첫번째 일은 백엔드 풀을 추가 하는. 이 과정을 통해 SQL 클러스터 Vm 있는 여부 설정을 선택 합니다. 그러나, 백 엔드 풀에 추가 하려면 실제 Vm을 선택 하면 반드시 파일 공유 감시를 선택 하지 마십시오. 우리는 파일 공유 미러링 모니터 SQL 트래픽을 리디렉션할 싶지 않습니다.
32
33

우리 할 것 이다 다음 것은 프로브를 추가. 프로브 추가 포트 59999 조사할 것 이다. 이 프로브는 노드는 우리의 클러스터 활성화를 결정 합니다.
34

그리고 마지막으로, 우리 SMB 트래픽을, 아래 스크린샷에서 통지를 중요 한 것은 활성화 되어 직접 서버 반환 TCP 포트 445 로드 균형 조정 규칙. 그 변경 다는 것을 확인 하십시오.

445_ilb

파일 서버 IP 리소스를 수정 합니다.

클러스터 노드 중 하나에서 다음 PowerShell 스크립트를 실행 하는 구성의 마지막 단계가입니다. 그러면 클러스터 IP 주소를 ILB 프로브에 응답 하 고 클러스터 IP 주소와는 ILB 사이 IP 주소 충돌 확인 하십시오. 주의 해 주시기 바랍니다. 사용자 환경에 맞게이 스크립트를 편집 해야 합니다. 서브넷 마스크는 255.255.255.255로 설정 됩니다, 이것은 실수를 하지, 그대로 두고. 이 ILB 함께 IP 주소 충돌을 피하기 위해 호스트 특정 경로를 만듭니다.

# 변수를 정의
$ClusterNetworkName = "" 
# 클러스터 네트워크 이름 
(이름을 찾기 위해 윈도우 서버 2012의 높은에 Get-ClusterNetwork 사용)
$IPResourceName = "" 
# IP 주소 리소스 이름 
$ILBIP = "" 
# 내부 부하 분산 장치 (ILB)의 IP 주소
가져오기 모듈 FailoverClusters
# 윈도 서버 2012 이상 사용 하는 경우:
Get-ClusterResource $IPResourceName | 세트-ClusterParameter 
-여러 @{주소 = $ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255";
네트워크 = $ClusterNetworkName; EnableDhcp = 0}
Windows Server 2008 r 2를 사용 하는 경우 #을 사용 하 여이. 
#cluster 해상도 $IPResourceName 사용 enabledhcp 0 주소 = $ILBIP probeport = 59999 =  
subnetmask = 255.255.255.255

파일 공유 만들기

장애 조치 클러스터 관리자에서 파일 공유 마법사를 사용 하 여 작동 하지 않는 것을 발견할 것 이다. 대신, 당신은 단순히 활성 노드에서 Windows 탐색기에서 파일 공유 만들 것 이다. 장애 조치 클러스터링 자동으로 공유를 선택 하 고 클러스터에 그들을 저장 합니다.

참고가이 구성에서의 파일 공유 "지속적인 가용성" 옵션이 지원 되지 않습니다.

결론

이제 파일 서버 장애 조치 클러스터를 작동 해야 합니다. 당신은 어떤 문제가 있는 경우, 트위터 @daveberm에 나에 게 연락 주시기 바랍니다. datakeeper 평가 키 필요 http://us.sios.com/clustersyourway/cta/14-day-trial에서 양식을 작성 하 고 sios는 사용자에 게 전송 된 평가 키를 보냅니다.

덩어리의 허락으로 재생산 됩니다.

Filed Under: Datakeeper, 서버 클러스터 단순화

  • « Previous Page
  • 1
  • …
  • 96
  • 97
  • 98

최근 게시물

  • SIOS LifeKeeper 데모: AWS에서 롤링 업데이트 및 장애 조치가 PostgreSQL을 보호하는 방법
  • 네트워크 카드를 교체해야 하는지 평가하는 방법
  • SIOS Technology, Red Hat Summit, Milestone Technology Day 및 XPerience Day, SQLBits 2025에서 미션 크리티컬 애플리케이션을 위한 고가용성 클러스터링 소프트웨어 시연
  • 고가용성과 관련된 애플리케이션 인텔리전스
  • Nutanix 환경에서 고가용성 솔루션을 선택하기 위한 10가지 고려 사항

가장 인기있는 게시물

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

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in