SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

Archives for 6월 2020

기업 가용성 : 법원의 교훈

6월 29, 2020 by Jason Aw Leave a Comment

기업 가용성 : 법원의 교훈

기업 가용성 : 법원의 교훈

나는 농구를 좋아합니다. 나는 그것을 즐기고,보고, 게임의 대뇌 측면을 통해 생각합니다. 생각과 동기, 전략 및 전술. 나는 작동하거나 실패하는 작은 것들, 화면이 너무 빨리 설정되거나 너무 늦게 롤을 찾고 싶습니다. 나는 방어와 회전을 좋아한다. 연습, 연습, 여행 등을위한 코치의 전략을 알고 싶습니다.  그래서 몇 달 전 24 시간 연중 무휴 이용 가능한 하루를 보내면서 자연스럽게 하루 종일 농구를 보러 갔고, 특히 딸의 중학교 농구 연습을 보았습니다.

시청하는 과정의 약 3 분의 1은 저를 포함 할 수 없었습니다. 나는 어린 소녀에게 휘파람을 불고 휘두르며 법정을 뛸 때“달려! 정력적 활동!" 그리고 그녀는 귀에 끼인 팀원들처럼 그랬습니다.  다음 몇 분, 놀이 및 훈련에는 에너지, 선명한 컷, 부드러운 움직임 및 운전으로 채워졌습니다.  그러나 지속되지 않았습니다.  대신, 더 많은 휘파람이 필요했고, 움직이고 뛰고, 열심히 뛰고, 날카로운 컷을 만들고, 다이빙하고,주의를 기울이고, 집중하고, 배우고, 수정해야 할 더 큰 호소력이있었습니다. 2 시간이 거의 끝났을 때 나는 마지막주의 순간에“연습 방식이 연주 방식이 될 것입니다!”라고 예언했습니다.

인공 지능 (AI), Allen Iverson (AI)이 아니라 인공 지능의 정신을 전달하는 것을 거의 느낄 수 있습니다.  “우리가 말하고있는 것은 연습입니다.  연습!" 나는 이것이 가용성에 관한 것이라고 생각했다.  농구에 대한 나의 사랑은 딸과 그녀의 팀원을 고려할 때 가용성에 대한 열정을 충족 시켰습니다. 어떻게?

농구 전략이 가용성 전략과 비슷한 세 가지 방법 :

  • 농구에서는 모든 팀에 엔터프라이즈 가용성을위한 계획이 필요합니다.
  • 농구에서 모든 팀은 해당 계획, 가용성, 재해 복구, 특히 계획된 유지 관리에 대한 개념을 연습해야합니다.
  • 농구에서, 불에 시험을 받았을 때 계획은 그 계획이 실시 된 것만 큼 만 유지 될 것입니다

엔터프라이즈 가용성에는 계획이 필요합니다 

가용성, 특히 재해, 계획된 유지 보수 및 중단 복구 전략은 사용자가 작성하는 것만 큼 좋습니다. 간단히 말해서, 중단 계획은 무엇입니까 (클라우드 장애, 서버 충돌, 네트워크 포화 및 인적 오류 – 충분하다고 말했습니다).  문서화 된 계획이 있습니까? 소유자 및 백업 소유자를 식별 했습니까? 아키텍처 및 토폴로지 (어떤 서버의 역할, 위치, 팀의 역할, 기능, 서비스 우선 순위, SLO / SLA 필요)를 알고 있습니까? 주요 공급 업체는 누구이며 콜 다운 목록은 무엇입니까? 체크 포인트, 데이터 보호 계획 및 백업 전략은 무엇입니까? 그리고이 계획의 검증을위한 테스트 계획 및 검증 계획은 무엇입니까?

엔터프라이즈 가용성 요구 연습 

좋은 계획입니다, 확인하십시오. 이제 연습은 어떻습니까?  재해 복구 단계 및 계획되지 않은 중단 전략을 구현하는 것은 모든 엔터프라이즈 구성의 필수 구성 요소입니다. 그러나 연습되지 않은 전략은 실제로 전략이 아닙니다. 이 경우 단순히 가능하고 제안 된 접근 방식입니다.  실제 기록 계획보다는 제안과 비슷합니다. 두 번째 단계는 연습입니다. 계획의 전략을 살펴보십시오. 유지 보수 타이밍을 연습하십시오. 백업 및 데이터를 복원하십시오. 가정 및 실패 모드를 확인하십시오.

엔터프라이즈 가용성에는 테스트가 필요합니다 

계획과 연습, 점검. 세 가지 중 두 가지를 갖추 었으니 딸의 팀으로 돌아가겠습니다.  “비공식 코치”로서의 이별의 말은 다음과 같습니다.“연습 방식은 연주 방식입니다!” 3 일 빨리 감습니다. 게임은 마지막 순간까지 진행됩니다. 그들이 뛰고있는 팀은 운동 적으로 일치하지 않으며 작년 경기가 절반으로 끝나고 작년과 같이 규모가 커졌다.  그러나 올해, 무자비하고 규모가 작은 팀은 더욱 준비가 잘되어있었습니다. 쉬운 승리 였어야했던 것은 이제 거의 결속 된 마지막 순간에 들어갑니다. 상대 팀 홈팀은 운명적인 연습을하는 동안 우연히도 무기력하지만 내 딸의 팀이 준비한 것을 언론에서 시작합니다.  그렇게 된 것은 예쁘지 않았습니다. 4 회의 비 강제 회전율, 3 점 시도 중 2 번의 치명적인 파울, 4 대 1 무패, 시간이 지남에 따라 엄청난 1 점 손실로 인한 좌절감.

마지막으로, 실제 정전, 재난 또는 계획된 유지 보수를 위해 얼마나 잘 연습하고 있습니까? 실제 데이터, 실제 고객 및 실제 긴급 성으로 연습하십니까? 고위 경영진은 얼마나 자주 체크인합니까? 압박감 넘치는 순간에 보스가 있으면 사람들이 이상하고 현명하지 않은 일을합니다! 샌드 박스 및 테스트 시스템이 프로덕션처럼 보입니까? 과거에는 제품과 QA간에 하드웨어, 스토리지 및 Linux OS 버전이 다른 고객과 일한 적이 있습니다. 그들이 응용 프로그램 업데이트를 시작했을 때, 재난이 닥쳤습니다.  테스트 중에 실행되는 사용자와 데이터 및 작업이 있습니까? 실제 재난 시뮬레이션은 어떻습니까? 삼키기 어려운 약, 잠재적으로 파괴적인 결과, 오프 사이트에서의 복구 및 동시 멀티 포인트, 다중 시스템 오류를 시뮬레이션하기가 더 어려운 하드 크래시 테스트, 실습은 종종 2 시간의 계획된 유지 보수로 전환하는 약점입니다 8 시간의 다중 팀 기업 재해.  실용적이지 않거나 실용적이지 못한 것은 전략과 팀에 대한 놀라운 승리 또는 팀, 공급 업체, 기업 및 고객에 대한 파괴적인 패배와 고비용의 차이입니다.

농구에서, 발사중인 계획은 계획이 실시 된만큼만 유지 될 것입니다.  복구 및 재해 계획을 구현할 때는 좋은 계획 및 유효성 검사가 핵심이지만 모범 사례는 왕입니다.

가용성 전문가 및 제품이 계획, 절차 및 실무에 도움을 줄 수있는 방법을 알아 보려면 SIOS 담당자에게 문의하십시오.

시뮬레이션을 피해서는 안되는 테스트에 대한 게시물을 다시 방문하십시오.

— Cassius Rhue, 고객 경험 부사장

SIOS에서 복제 된 기사

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

단계별 : Azure의 ISCSI 대상 서버 클러스터

6월 13, 2020 by Jason Aw Leave a Comment

Azure의 단계별 단계별 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

최근에 누군가가 Azure에서 iSCSI 대상 서버 클러스터를 구축하도록 도왔으며 해당 특정 구성에 대한 단계별 가이드를 작성하지 않았다는 것을 깨달았습니다. 이를 해결하기 위해 직접 수행해야 할 경우를위한 단계별 지침이 있습니다.

전제 조건

Azure 및 Windows Server에 대해 잘 알고 있다고 가정하겠습니다. 따라서 세부 정보를 아끼지 않겠습니다. 최소한 전제 조건으로 다음을 수행했다고 가정 해 봅시다.

  • 서로 다른 가용 영역에 각각 두 개의 서버 (SQL1, SQL2)를 프로비저닝하십시오 (가용성 세트도 가능하지만 가용 영역이 더 나은 SLA를 가짐)
  • Azure Portal을 통해 고정 IP 주소를 할당
  • 서버를 기존 도메인에 가입
  • 두 노드 모두에서 장애 조치 클러스터링 기능 및 iSCSI 대상 서버 기능을 활성화했습니다.
  • 각 노드에 3 개의 Azure Premium Disk를 추가하십시오.
    참고 : 이것은 선택 사항이며 최소 하나의 디스크가 필요합니다. IOPS를 늘리기 위해 스토리지 풀에서 3 개의 프리미엄 Azure 디스크를 함께 스트라이핑하고 간단한 (RAID 0) 가상 디스크를 만듭니다.
  • SIOS DataKeeper는 클러스터에서 사용되는 복제 된 스토리지를 제공하는 데 사용됩니다. DataKeeper가 필요한 경우 여기에서 평가판을 요청할 수 있습니다.

로컬 스토리지 풀 생성

다시 한 번이 단계는 완전히 선택 사항이지만 IOPS를 높이기 위해 3 개의 Azure Premium 디스크를 단일 저장소 풀로 스트라이프합니다. 대신 동적 디스크와 스팬 볼륨을 사용하고 싶을 수도 있지만 그렇게하지 마십시오! 동적 디스크를 사용하는 경우 나중에 iSCSI 대상을 만들지 못하게하는 일반적인 비 호환성이 있음을 알 수 있습니다.

걱정하지 마십시오. 아래 설명에 따라 발생할 수있는 함정을 알고 있다면 로컬 스토리지 풀을 만드는 것이 매우 간단합니다. 공식 문서는 여기에서 찾을 수 있습니다.

함정 # 1 – 설명서에 스토리지 풀에 사용되는 볼륨의 최소 크기가 4GB라고 나와 있지만 P1 프리미엄 디스크 (4GB)가 인식되지 않는 것으로 나타났습니다. 실험실에서는 16GB P3 프리미엄 디스크를 사용했습니다.

함정 # 2 – 스토리지 풀을 만들려면 3 개 이상의 디스크가 있어야합니다.

함정 # 3 – 클러스터를 만들기 전에 저장소 풀을 만듭니다. 클러스터를 만든 후 클러스터를 만들려고하면 Microsoft가 클러스터 저장소 풀을 만들려고 할 때 큰 혼란에 빠질 것입니다. 클러스터 저장 영역 풀을 작성하지 않으므로 클러스터를 작성하기 전에 저장 영역 풀을 작성하여 혼란을 피하십시오. 클러스터가 작성된 후 스토리지 풀을 추가해야하는 경우 먼저 클러스터에서 노드를 제거하고 스토리지 풀을 작성해야합니다.

여기에있는 설명서를 기반으로 아래에 두 클러스터 노드 각각에 로컬 스토리지 풀을 구축 할 때 표시되는 스크린 샷이 나와 있습니다. 클러스터를 빌드하기 전에 두 서버 모두에서이 단계를 완료하십시오.

단계별 : Azure의 ISCSI 대상 서버 클러스터

두 서버 모두에 기본 풀이 나타납니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

마우스 오른쪽 단추를 클릭하고 새 스토리지 풀…을 선택하십시오.

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

이 마법사를 닫을 때 가상 디스크 생성을 선택하십시오

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

Standard, Premium 및 Ultra SSD의 조합을 사용하기로 결정한 경우 스토리지 계층을 생성 할 수 있습니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

최상의 성능을 위해서는 단순 스토리지 레이아웃 (RAID 0)을 사용하십시오. Azure Managed Disks에는 백엔드에 3 중 중복성이 있으므로 안정성에 대해 걱정하지 마십시오. 최적의 성능을 위해서는 단순이 필요합니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

성능을 위해 고정 프로비저닝을 사용하십시오. 어쨌든 전체 프리미엄 디스크에 대한 비용을 이미 지불하고 있으므로 모든 것을 사용할 필요는 없습니다.단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

이제 첫 번째 노드에 45GB X 드라이브가 있습니다. 두 번째 노드에 대해이 전체 프로세스를 반복하십시오.

클러스터 생성

각 서버마다 각각 45GB X 드라이브가 있으므로 기본 클러스터를 만들 것입니다. Azure에서 클러스터 생성은 정적 IP 주소를 지정할 수 있도록 Powershell을 통해 가장 잘 수행됩니다. GUI를 통해이 작업을 수행하면 Azure에서 정리해야 할 중복 IP 주소에 클러스터 IP를 할당한다는 사실을 곧 알게 될 것입니다.

다음은 새로운 클러스터를 생성하는 Powershell 코드의 예입니다.

 새 클러스터-이름 mycluster -NoStorage -StaticAddress 10.0.0.100-노드 sql1, sql2

출력은 다음과 같습니다.

PS C :  Users  dave.DATAKEEPER> 새 클러스터-이름 mycluster -NoStorage 
-StaticAddress 10.0.0.100-노드 sql1, sql2
경고 : 클러스터 된 역할을 만드는 동안 문제가 발생했습니다. 
시작하지 못할 수 있습니다. 
자세한 내용은 아래 보고서 파일을보십시오.
경고 : 보고서 파일 위치 : C :  windows  cluster  Reports  Create Cluster 
2020.05.20의 마법사 mycluster 
16.54.45.htm에서

이름     
----     
mycluster

보고서의 경고는 증인이 없다는 것을 알려줍니다. 이 클러스터에는 공유 스토리지가 없으므로 "Cloud Witness"또는 "File Share Witness"를 만들어야합니다. 해당 링크에 문서화되어 있으므로 해당 프로세스를 진행하지 않겠습니다.

다음 단계로 넘어 가기 전에 지금 이것을 막지 말고 지금 증인을 만드십시오!

이제 다음과 같은 기본 2 노드 클러스터가 있어야합니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

클러스터 코어 IP 주소에 대한로드 밸런서 구성

Azure의 클러스터는 Azure 가상 네트워크가 무상 ARP를 지원하지 않는다는 점에서 고유합니다. 이것이 의미하는 바를 모르더라도 걱정하지 마십시오. 실제로 알아야 할 것은 클러스터 IP 주소에 직접 연결할 수 없다는 것입니다. 대신 클라이언트 연결을 활성 클러스터 노드로 리디렉션하는 Azure Load Balancer를 사용해야합니다.

Azure에서 클러스터에 대해로드 밸런서를 구성하려면 두 단계가 있습니다. 첫 번째 단계는로드 밸런서를 생성하는 것입니다. 두 번째 단계는 클러스터 IP 주소를 업데이트하여로드 밸런서의 상태 프로브를 수신하고 ILB와의 IP 주소 충돌을 피할 수있는 255.255.255.255 서브넷 마스크를 사용하는 것입니다.

먼저 클러스터 코어 IP 주소에 대한로드 밸런서를 생성합니다. 나중에이 문서 끝에 생성 될 iSCSI 클러스터 리소스 IP 주소를 처리하기 위해로드 밸런서를 편집합니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

사용중인 고정 IP 주소는 코어 클러스터 IP 리소스를 생성 할 때 사용한 주소와 동일합니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

로드 밸런서가 생성되면 아래와 같이로드 밸런서를 편집합니다

단계별 : Azure의 ISCSI 대상 서버 클러스터

백엔드 풀에 두 개의 클러스터 노드 추가

단계별 : Azure의 ISCSI 대상 서버 클러스터

백엔드 풀에 두 개의 클러스터 노드 추가

단계별 : Azure의 ISCSI 대상 서버 클러스터

건강 프로브를 추가하십시오. 이 예에서는 59999를 포트로 사용합니다. 그 포트를 기억하십시오. 다음 단계에서 포트가 필요합니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

모든 HA 포트를 리디렉션하기 위해 새 rue를 작성하십시오. 유동 IP가 사용 가능한지 확인하십시오.

2 단계 –로드 밸런서와 작동하도록 코어 IP 주소를 클러스터링하도록 편집

앞에서 언급했듯이로드 밸런서가 올바르게 작동하도록 구성하는 두 단계가 있습니다. 이제로드 밸런서가 있으므로 클러스터 노드 중 하나에서 Powershell 스크립트를 실행해야합니다. 다음은 클러스터 노드 중 하나에서 실행해야하는 스크립트 예입니다.

$ ClusterNetworkName =“클러스터 네트워크 1” 
$ IPResourceName =“클러스터 IP 주소” 
$ ILBIP =“10.0.0.100” 
가져 오기 모듈 페일 오버 클러스터
Get-ClusterResource $ IPResourceName | 클러스터 매개 변수 설정 
-여러 @ {Address = $ ILBIP; ProPortPort = 59998; SubnetMask = "255.255.255.255"
; Network = $ ClusterNetworkName; EnableDhcp = 0} 

위의 스크립트에서 중요한 것은 사용자 환경에 맞는 모든 변수를 얻는 것 외에도 ProbePort가이 특정 IP 주소에 대한로드 밸런서 설정에서 정의한 것과 동일한 포트로 설정되어 있는지 확인하는 것입니다. 나중에 다른 포트를 사용하는 iSCSI 클러스터 IP 리소스에 대한 두 번째 상태 프로브를 생성 할 것입니다. 다른 중요한 점은 서브넷 세트를 255.255.255.255로 두는 것입니다. 잘못 보일 수도 있지만 이것이 바로 설정해야합니다.

실행 한 후 출력은 다음과 같아야합니다.

 PS C :  Users  dave.DATAKEEPER> $ ClusterNetworkName =“클러스터 네트워크 1” 
$ IPResourceName =“클러스터 IP 주소” 
$ ILBIP =“10.0.0.100” 
가져 오기 모듈 페일 오버 클러스터
Get-ClusterResource $ IPResourceName | 클러스터 매개 변수 설정 
-여러 @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255"
; Network = $ ClusterNetworkName; EnableDhcp = 0}
경고 : 속성이 저장되었지만 모든 변경 사항이 적용되는 것은 아닙니다 
클러스터 IP 주소가 오프라인이 된 후 다시 온라인이 될 때까지.

로드 밸런서에서 제대로 작동하려면 코어 클러스터 IP 리소스를 오프라인으로 전환 한 후 다시 온라인 상태로 만들어야합니다.

로드 밸런서를 생성하는 데 모든 작업을 올바르게 수행했다고 가정하면 두 서버의 서버 관리자는 아래 표시된 것처럼 클러스터를 온라인으로 나열해야합니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

두 클러스터 노드에서 서버 관리자를 확인하십시오. 클러스터는 관리 효율성에서 "온라인"으로 표시되어야합니다.

DataKeeper 설치

여기서는 모든 단계를 수행하지는 않지만 기본적으로 두 클러스터 노드에 SIOS DataKeeper를 설치할 수 있습니다. 아주 간단한 설정입니다. 설정을 실행하고 모든 기본값을 선택하십시오. DataKeeper에 문제가 발생하면 대개 두 가지 중 하나입니다. 첫 번째 문제는 서비스 계정입니다. DataKeeper 서비스를 실행하는 데 사용중인 계정이 각 노드의 로컬 관리자 그룹에 있는지 확인해야합니다.

두 번째 문제는 방화벽과 관련이 있습니다. DataKeeper를 설치하면 로컬 Windows 방화벽이 자동으로 업데이트되지만 네트워크가 잠긴 경우 필요한 DataKeeper 포트를 통해 클러스터 노드가 서로 통신 할 수 있는지 확인해야합니다. 또한 ILB 상태 프로브가 서버에 도달 할 수 있는지 확인해야합니다.

DataKeeper가 설치되면 첫 번째 DataKeeper 작업을 작성할 수 있습니다. DataKeeper 인터페이스를 사용하여 복제하려는 각 볼륨에 대해 다음 단계를 완료하십시오.

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

DataKeeper 인터페이스를 사용하여 두 서버에 연결

단계별 : Azure의 ISCSI 대상 서버 클러스터

새 직업 만들기를 클릭하고 이름을 지정하십시오.

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

클러스터에 DataKeeper 볼륨을 등록하려면 예를 클릭하십시오.

단계별 : Azure의 ISCSI 대상 서버 클러스터

볼륨이 등록되면 Failover Cluster Manager의 사용 가능한 스토리지에 나타납니다

ISCSI 대상 서버 클러스터 생성

다음 단계에서는 클러스터에서 iSCSI 대상 서버 역할을 생성합니다. 이상적인 세상에서 나는 당신을 위해이 모든 것을 수행하는 Powershell 스크립트를 가지고 있지만 지금 당장은 GUI를 통해 그것을 수행하는 방법을 보여 드리겠습니다. Powershell 코드를 작성하는 경우 언제든지 나머지 사람들과 공유하십시오!

GUI 방법에는 한 가지 문제가 있습니다. ou는 IP 리소스가 생성 될 때 중복 IP 주소로 시작되어 클러스터 리소스가 수정 될 때까지 실패합니다. 그 과정도 함께 진행하겠습니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

실패한 IP 주소 리소스의 속성으로 이동하여 고정 IP를 선택하고 네트워크에서 사용하지 않는 IP 주소를 선택하십시오. 이 주소를 기억하십시오.로드 밸런서를 업데이트 할 때 다음 단계에서 사용합니다.

이제 iSCSI 클러스터 리소스를 온라인 상태로 만들 수 있습니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

ISCSI 대상 서버 클러스터 리소스 용로드 밸런서 업데이트

앞에서 언급 한 것처럼 클라이언트는 방금 iSCSI 대상 서버 클러스터 용으로 만든 클러스터 IP 주소 (10.0.0.110)에 직접 연결할 수 없습니다. 아래와 같이 앞에서 만든로드 밸런서를 업데이트해야합니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

iSCSI 대상 클러스터 IP 리소스와 동일한 IP 주소를 사용하는 새로운 프런트 엔드 IP 주소를 추가하여 시작하십시오.

단계별 : Azure의 ISCSI 대상 서버 클러스터

다른 포트에 두 번째 상태 프로브를 추가하십시오. 이 포트 번호를 기억하십시오. 다음에 실행할 powershell 스크립트에서 다시 사용합니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

부하 분산 규칙을 하나 더 추가합니다. 방금 만든 주소를 사용하도록 프론트 엔드 IP 주소 및 상태 프로브를 변경하십시오. 또한 직접 서버 리턴이 사용 가능한지 확인하십시오.

로드 밸런서가 작동하게하는 마지막 단계는 클러스터 노드 중 하나에서 다음 Powershell 스크립트를 실행하는 것입니다. 새로운 Healthprobe 포트, IP 주소 및 IP 리소스 이름을 사용해야합니다.

 $ ClusterNetworkName =“클러스터 네트워크 1” 
$ IPResourceName =“IP 주소 10.0.0.0” 
$ ILBIP =“10.0.0.110” 
가져 오기 모듈 페일 오버 클러스터
Get-ClusterResource $ IPResourceName | 클러스터 매개 변수 설정 
-여러 @ {Address = $ ILBIP; ProPortPort = 59998; SubnetMask = "255.255.255.255"
; Network = $ ClusterNetworkName; EnableDhcp = 0} 

출력은 다음과 같아야합니다.

 PS C :  Users  dave.DATAKEEPER> $ ClusterNetworkName =“클러스터 네트워크 1” 
$ IPResourceName =“IP 주소 10.0.0.0” 
$ ILBIP =“10.0.0.110” 
가져 오기 모듈 페일 오버 클러스터
Get-ClusterResource $ IPResourceName | 클러스터 매개 변수 설정 
-여러 @ {Address = $ ILBIP; ProPortPort = 59998; SubnetMask = "255.255.255.255"
; Network = $ ClusterNetworkName; EnableDhcp = 0}
경고 : 속성이 저장되었지만 모든 변경 사항이 적용되는 것은 아닙니다 
IP 주소 10.0.0.0이 오프라인 상태가 된 후 다시 온라인 상태가 될 때까지.

설정을 적용하려면 리소스를 오프라인 및 온라인 상태로 만들어야합니다.

클러스터 된 ISCSI 대상 생성

시작하기 전에 두 서버의 서버 관리자가 두 개의 클러스터 노드와 두 개의 클러스터 이름 리소스를 볼 수 있는지 확인하고 아래 표시된 것처럼 관리 효율성 아래에 모두 "온라인"으로 표시되는지 확인하는 것이 가장 좋습니다.

단계별 : Azure의 ISCSI 대상 서버 클러스터

두 서버 중 하나에 해당 클러스터 이름을 쿼리하는 데 문제가 있으면 다음 단계는 실패합니다. 문제가 발생하면로드 밸런서 및 Powershell 스크립트를 생성하기 위해 수행 한 모든 단계를 다시 확인하십시오.

이제 첫 번째 클러스터 된 iSCSI 대상을 만들 준비가되었습니다. 클러스터 노드 중 하나에서 iSCSI 대상을 작성하는 방법에 대한 예제로 아래에 설명 된 단계를 따르십시오.

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

물론이 서버를이 iSSI 대상에 연결할 서버에 할당하십시오.

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

단계별 : Azure의 ISCSI 대상 서버 클러스터

거기에 이제 Azure에 작동하는 iSCSI 대상 서버가 있습니다.

당신이 이것을 구축하면 의견을 남기고 당신이 그것을 어떻게 사용할 계획인지 알고 있습니다!

치명적이지 않은 클러스터링의 허가를 받아 복제 된 기사

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

솔루션 요약 : 하이브리드 클라우드 환경을위한 SANless 클러스터

6월 9, 2020 by Jason Aw Leave a Comment

하이브리드 클라우드 환경을위한 SANless 클러스터

솔루션 요약 : 하이브리드 클라우드 환경을위한 SANless 클러스터

SIOS SANless 클러스터는 추가 데이터 센터 또는 재해 복구 사이트의 비용과 복잡성없이 물리적 서버 기반 클러스터 환경에 재해 방지를 추가 할 수있는 쉽고 비용 효율적인 방법입니다. 클라우드의 SIOS SANless 클러스터 노드를 실제 서버 기반 클러스터 환경에 추가하여 비즈니스 크리티컬 애플리케이션을위한 효율적인 실시간 블록 레벨 복제 및 재해 보호를 제공하십시오. SIOS 소프트웨어를 사용하면 지리적 위치 및 클라우드 가용 영역 또는 지역에서 응용 프로그램 인스턴스를 장애 조치하여 사이트 전체, 지역 및 지역 재난 보호 기능을 제공 할 수 있습니다. SIOS SANless 소프트웨어를 사용하면 물리적, 가상 또는 클라우드 시스템에서 사용 가능한 로컬 스토리지를 사용하여 클러스터를 구축 할 수 있습니다. SIOS 소프트웨어는 공유 스토리지가 없어도 고 가용성 보호를 위해 로컬 스토리지를 동기화 된 상태로 유지합니다.

구성 유연성

SIOS SANless 소프트웨어는 물리적 서버, 조직 내의 프라이빗 클라우드, 퍼블릭 클라우드 또는 하이브리드 클라우드의 애플리케이션을 보호하려는 경우 원하는대로 완전 자동화 된 애플리케이션 중심 클러스터 및 복제 솔루션을 구축 할 수있는 유연성을 제공합니다. 업계 표준 하드웨어, 복제 스키마 및 배포 (활성 / 활성, 활성 / 수동)

하이브리드 클라우드 환경을위한 SANless 클러스터
SIOS SANless 클러스터는 환경 전반에 걸쳐 원격 재해 복구 사이트의 비용과 복잡성없이 고 가용성 및 재해 복구로 데이터를 보호 할 수 있습니다.

SIOS 소프트웨어를 사용하면 SAN 및 SANless 환경과 물리적, 가상 및 클라우드 구성의 조합 사이에서 선택한 구성간에 복제 할 수 있습니다. 공급 업체 잠금이 없습니다. 소스와 대상에서 동일한 하드웨어가 필요하지 않습니다.

사용하기 쉬운. 소유하기 쉽다

직관적 인 인터페이스를 사용하여 SIOS SANless 클러스터를 구축하고 몇 분 안에 구성 할 수 있습니다. SIOS는 또한 클러스터의 모니터링 및 관리를 쉽게 해줍니다. 사용하기 쉬운 관리 콘솔을 사용하면 보호 서버, 통신 경로, 리소스 및 응용 프로그램의 상태를 한눈에 모니터링 할 수 있습니다.

주요 혜택

방재

• 비즈니스 크리티컬 애플리케이션을위한 쉽고 비용 효율적인 고 가용성 및 재해 보호

적응성

• 물리적 서버와 클라우드 환경을 혼합하여 효율성을 극대화합니다.

사용의 용이성

• 지속적인 지속적인 모니터링 및 관리를위한 직관적 인 콘솔.

하이브리드 클라우드 환경을위한 SANless 클러스터에 대한 솔루션 요약 다운로드

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

솔루션 요약 : 가상 서버 환경을위한 SANless 클러스터 솔루션

6월 9, 2020 by Jason Aw Leave a Comment

가상 서버 환경을위한 SANless 클러스터 솔루션

솔루션 요약 : 가상 서버 환경을위한 SANless 클러스터 솔루션

SIOS SANless 소프트웨어를 사용하면 공유 스토리지가 없어도 가상화 된 환경에서 클러스터를 구축 할 수 있습니다. 하이퍼 바이저가 제공하고 제공하는 모든 로컬 스토리지 유형을 사용할 수 있습니다. SIOS 소프트웨어는 효율적인 블록 수준 복제를 사용하여 로컬 스토리지를 동기화하여 가장 최신 데이터에 액세스하여 장애 조치 후에도 클러스터의 대기 서버가 계속 작동 할 수 있도록합니다.

클러스터 가상 머신

SIOS SANless 소프트웨어를 사용하면 모든 하이퍼 바이저 (VMware, Xen, Microsoft Hyper-V 등) 위에있는 가상 머신을 사용하여 클러스터를 작성할 수 있습니다. 실시간 복제를 사용하여 기본 VM의 스토리지를 동일한 데이터 센터, 재해 복구 사이트 또는 둘 다에있는 대기 VM의 스토리지와 동기화합니다. 재해가 발생하면 대기 VM을 즉시 서비스 할 수 있으므로 백업 미디어에서 복원하는 데 필요한 시간을 제거 할 수 있습니다. DR 사이트에서 복제 된 VM에 직접 액세스하기 만하면됩니다.

라이브 마이그레이션을 지원하는 Hyper-V 호스트 클러스터링

Microsoft Hyper-V 환경에서 SIOS SANless 소프트웨어를 사용하면 하이퍼 바이저 수준에서 전체 Hyper-V 호스트 시스템을 클러스터링하여 완전한 VM 이식성과 장애 조치 보호 기능을 사용할 수 있습니다. SIOS 소프트웨어는 실행중인 VM의 실시간 사본을 대체 Hyper-V 호스트에서 동기화 된 상태로 유지함으로써 한 Hyper-V 호스트에서 다른 Hyper-V 호스트로 VM을 쉽게 페일 오버하거나 Live Migrate 할 수 있습니다. 호스트의 개별 VM 또는 모든 VM을 클러스터의 다른 Hyper-V 호스트로 이동할 수있는 완벽한 이식성을 제공합니다.

가상 서버 (A)를 사용하여 SIOS SANless 클러스터를 구축하십시오. Microsoft Hyper-V 환경 (B)에서 SIOS SANless 클러스터는 가상 머신 수준에서 쉽게 라이브 마이그레이션 및 완벽한 서버 이식성을 위해 사용할 수 있습니다.

손쉬운 재해 복구 테스트

SIOS 소프트웨어를 사용하면 복제 된 VM을 복원하여 프로덕션 사이트를 중단하지 않고도 재해 복구 테스트를 수행 할 수 있습니다. 테스트가 완료되면 SIOS 소프트웨어는 테스트 중에 대상 서버에서 작성된 변경 사항을 제거하고 중지 된 위치에서 복제를 재개합니다.

가상 서버 환경을위한 SANless 클러스터 솔루션에 대한 솔루션 요약 다운로드

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

최근 게시물

  • Nutanix 환경에서 고가용성 솔루션을 선택하기 위한 10가지 고려 사항
  • 내 서버는 일회용인가요? 고가용성 소프트웨어가 클라우드 모범 사례에 어떻게 적용되는가?
  • 재난에 취약한 세상을 위한 데이터 복구 전략
  • DataKeeper와 Baseball: 재해 복구에 대한 전략적 접근
  • SQL Server 가동 중지 위험에 대한 예산 책정

가장 인기있는 게시물

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

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