테스트 / QA 시스템은 엔터프라이즈 가용성의 중요한 부분입니다

“내가 너에게 키스 할 수있어.”그것이 30여 년 전에 친구가 나를 향해 달려 갔을 때 친구가 나에게 쏟아져 나온 것입니다. 그녀는 우리 지역에서 가장 큰 밴드 대회 중 하나에가는 길에 색소폰에 대한 갈대를 떨어 뜨 렸습니다. 나는 그들이 누구인지 몰랐지만, 버스의 좌석에서 갈대 팩을 보았을 때 데리러 데려 가서 워밍업 지역으로 데려갔습니다. 워밍업을 시작한지 3 분이 지난 후, 그녀의 첫 번째 갈대는 금이 갔고, 빈 주머니에 손을 대고 빈둥 거리며 놀랐습니다. 내가 찾은 줄 알았을 때, 그녀는“지금 당장 키스 할 수 있습니다.”

SIOS Technology Corp.의 고객 경험 부사장 가용성 스펙트럼의 다른 단계에서 여러 엔터프라이즈 고객 및 파트너와 함께 일할 수있는 독특하고 뚜렷한 즐거움이 있습니다. 때때로 문제 해결, 완화 및 개선을 위해 최종 고객과 협력 할 기회가 있습니다. 때때로 우리 팀은 파트너 및 고객과 적극적으로 협력하여 시스템 다운 타임을 방지하기 위해 엔터프라이즈 가용성을 설계하고 구현합니다. 최근 고객 경험을 통해 거의 30 년 전에 제 친구가“당신에게 키스 할 수 있습니다”라는 말이 흐려 졌던 일을 떠올리게되었습니다.

우리 팀과 저는 고객 통화 중이었습니다. 전화는 일반적인 즐거움, 소개 및 고객의 엔터프라이즈 환경에 대한 개요로 시작되었습니다. 30 분이 지났을 때 일이 잘 진행되고있었습니다. 그들의 아키텍처는 견고하고 사려 깊으며 잘 문서화되었습니다. 그들의 팀은 지식이 풍부하고 기술적으로 건전하며 경험이 풍부했습니다. 그러나 고객은 비용 절감으로 인해 전용 테스트 / 품질 시스템을 유지할 계획이 아니라고 생각했습니다. 나는 심호흡했다.  실제로 그것은 내장 펀치에서 공기가 서두르는 것과 같은 숨을 내쉬었습니다. 응답 할 준비가되었지만 목소리가 들리기 전에  "중단 시간의 원인 중 하나는 프로세스가 부족하기 때문입니다."라고 Partner Rep Architect는 전화를 걸어 설명했습니다. 간단한 헛소리 후, 고객은 테스트 / QA 시스템을 유지하기로 동의했고 나는“당신에게 키스 할 수 있습니다!”

많은 엔터프라이즈 배포 (최신 시스템, 데이터 센터 마이그레이션 및 시스템 업데이트)의 최전선에서 지원 및 서비스 팀은 테스트 시스템 / 클러스터를 사용하여 중재 할 수있는 수십 가지 문제를 발견했습니다.

테스트 / 품질 시스템은 다운 타임을 피하기위한 HA 전략에서 매우 중요한 부분입니다. 패치, 업데이트 및 구성 변경과 같은 엔터프라이즈 배포 유지 관리와 관련된 일반적인 작업에는 위험이 따릅니다. 엄청난 위험.

생산 테스트에서 일반적으로 식별되는 위험에는 몇 가지 심각하고 잠재적으로 치명적인 문제가 포함됩니다. 

• 손상되었거나 유효하지 않은 데이터
• 유출 된 보호 데이터
• 잘못된 수익 인식 (취소 된 주문 등)
• 과부하 시스템
• 의도하지 않은 부작용 또는 다른 생산 시스템에 미치는 영향
• 경고를 설정하고 호출중인 사람들을 호출하는 높은 오류율
• 비뚤어진 분석 (트래픽 퍼널, A / B 테스트 결과 등)
• 스크립트 및 봇 활동으로 가득 찬 부정확 한 트래픽 로그 (a)

고객이 생산 과정에서 위험한 변경 사항을 적용하려고하면 결과가 상당히 손상 될 수 있습니다. 위에 나열된 것 외에도 가동 중지 시간, 응용 프로그램 설치 손상 및 돌이킬 수없는 손상의 위험이 증가합니다. Customer X (제조 산업의 유명한 SAP Enterprise 상점)를 예로 들어 보겠습니다.

평판이 좋은 사이트에서 중요한 알림을 읽은 후 OS 관리자는 프로덕션 노드를 사용 가능한 최신 커널 업데이트로 빠르게 업데이트했습니다. 몇 시간 안에 프로덕션 노드는 시작되지 않은 일련의 충돌 및 커널 패닉을 시작했습니다. 그는 서둘러 자신의 구성과 호환되지 않는 커널을 설치했습니다. 기존 응용 프로그램 패키지, 장치, 파일 시스템 및 관련 패키지의 조합 이로 인해 생산 중단이 발생하고 여러 공급 업체로 우선 순위가 높아졌습니다.

패치가 테스트 / QA 또는 샌드 박스 시스템에 적용될 때, 패치 및 중요 수정 사항을 관리 및 검증하여 생산성 손실 및 계획되지 않은 다운 타임을 줄입니다. 프로덕션 환경에서 응용 프로그램을 테스트하면 예기치 않은 문제를 식별하고 문제가 운영에 부정적인 영향을 미치기 전에 문제를 해결할 수 있습니다. 사전 프로덕션 디자인 및 테스트는 비용이 많이 드는 비즈니스 중단을 없애고 고객 경험을 개선하며 브랜드를 보호합니다.

테스트 QA 시스템을 사용하여 생산 가용성 및 프로세스 개선

테스트 / QA 시스템을 사용하여 생산 가용성 및 프로세스를 개선 할 수있는 기본 사항은 다음과 같습니다. 프로덕션 환경과 유사한 제어 가능한 환경 (가능한 한 프로덕션과 유사해야 함)은 다음과 같은 기능을 제공합니다.

1. 커널 업데이트 및 보안 업데이트 테스트
2. 설정 및 구성 조정 확인
3. 생산 문제 재현 및 소프트웨어 업데이트 및 패치 테스트
4. 호환되지 않는 변경으로 인한 응용 프로그램 버전 호환성 확인 및 다운 타임 위험 감소
5. 이동, 유지 보수, 중단 및 기타 기업 절차 활동을 연습하고 수정할 수있는 안전한 공간 제공
6. 엔터프라이즈 고객에게 영향을주지 않으면 서 신규 직원 및 팀원 교육

중요한 엔터프라이즈 가용성 소프트웨어를 배포하기위한 Test / QA 환경이 있다면 지금 바로 키스 할 수 있습니다. 이 환경을 갖추면 팀이 "테스트, 검증 및 검증 (2)"아키텍처, 비즈니스 요구 사항, 사용자 시나리오 및 프로덕션 환경과 가장 유사한 시스템 또는 시스템 세트와의 일반적인 통합 기능을 얻을 수 있습니다. 돈을 벌어. 물론 프로덕션 시스템을 유지 관리하고 테스트를 수행하기 위해 창을 예약해야하지만 그 사이에 안전한 버퍼 단계가 완료된 후에야합니다.

— Cassius Rhue, 고객 경험 부사장

————-

참고 문헌 :

1. https://opensource.com/article/19/5/dont-test-production 액세스 5/4/2020
2. https://www.softwaretestingclass.com/system-testing-what-why-how/ 액세스 5/4/2020

기업 가용성 : 법원의 교훈

나는 농구를 좋아합니다. 나는 그것을 즐기고,보고, 게임의 대뇌 측면을 통해 생각합니다. 생각과 동기, 전략 및 전술. 나는 작동하거나 실패하는 작은 것들, 화면이 너무 빨리 설정되거나 너무 늦게 롤을 찾고 싶습니다. 나는 방어와 회전을 좋아한다. 연습, 연습, 여행 등을위한 코치의 전략을 알고 싶습니다.  그래서 몇 달 전 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에서 복제 된 기사

단계별 : 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가 클러스터 저장소 풀을 만들려고 할 때 큰 혼란에 빠질 것입니다. 클러스터 저장 영역 풀을 작성하지 않으므로 클러스터를 작성하기 전에 저장 영역 풀을 작성하여 혼란을 피하십시오. 클러스터가 작성된 후 스토리지 풀을 추가해야하는 경우 먼저 클러스터에서 노드를 제거하고 스토리지 풀을 작성해야합니다.

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

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

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

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

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

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

성능을 위해 고정 프로비저닝을 사용하십시오. 어쨌든 전체 프리미엄 디스크에 대한 비용을 이미 지불하고 있으므로 모든 것을 사용할 필요는 없습니다.

클러스터 생성

각 서버마다 각각 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 노드 클러스터가 있어야합니다.

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

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

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

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

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

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

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

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

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

모든 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 리소스를 오프라인으로 전환 한 후 다시 온라인 상태로 만들어야합니다.

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

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

DataKeeper 설치

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

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

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

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

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

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

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

ISCSI 대상 서버 클러스터 생성

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

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

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

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

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

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

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

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

부하 분산 규칙을 하나 더 추가합니다. 방금 만든 주소를 사용하도록 프론트 엔드 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 대상 생성

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

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

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

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

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

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

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

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

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

구성 유연성

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

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

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

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

주요 혜택

방재

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

적응성

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

사용의 용이성

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

하이브리드 클라우드 환경을위한 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 클러스터 솔루션에 대한 솔루션 요약 다운로드