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

사례 연구 : AWS EC2 Monitoring Solution은 글로벌 제조 회사가 클라우드로 이전함에 따른 스트레스를 덜어줍니다.

SIOS AppKeeper로 중요한 애플리케이션을 보호하는 도쿄 다이아몬드 툴 제조

1932 년에 설립 된 Tokyo Diamond Tools Mfg. Co., Ltd.는 가전, 반도체, 전자 기기, 의료 및 토목 공학과 같은 다양한 분야에서 절단, 슬라이싱, 연마 및 드릴링 공정을위한 다이아몬드 공구를 제조합니다. 80 년이 넘는 역사를 가진 오래된 회사이지만 도쿄 다이아몬드는 항상 적극적으로 새로운 IT 도구를 도입 해 왔습니다.  이 회사는 비즈니스 개선 속도와 효율성을 위해 Amazon AWS 및 가상화로 전환하기로 결정했습니다. SIOS AppKeeper는 필요한 응용 프로그램 가용성 보호 기능을 제공하는 데 중요한 역할을했습니다. Tokyo Diamond Tools가 클라우드로 전환 한 이유 중 하나는 AWS의 2011 년 동일본 대지진이었습니다.  본사의 서버에 직접적인 피해는 없었지만 미야기 현 센다이 공장의 장비는 랙에서 떨어져 심각한 손상을 일으켰습니다.  도쿄 다이아몬드는 더 나은 비즈니스 연속성 계획의 필요성을 보았습니다.  이는 핵심 시스템 가상화 및 클라우드 환경 사용으로의 전환을위한 주요 동인이었습니다.

처음에 회사는 비교적 작은 애플리케이션을 클라우드로 마이그레이션하기 시작했습니다.  “우리는 2011 년 11 월경에 이사를 시작했습니다.  당시에는 AWS 외에는 선택의 여지가 없었습니다.”도쿄 다이아몬드의 IT 시스템 책임자 인 Takuji Kokubo는 말했습니다.  그들은 Sony Network Communications의“Managed Cloud with AWS”클라우드 포털을 사용하여 운영을 관리했습니다.  Kokubo는 자체 설명 된 "One Man IT 운영"이므로 효율성과 자동화는 일본과 싱가포르 및 태국에서 회사의 IT 시스템을 원활하게 운영 할 수 있도록하는 데 중요합니다.

클라우드로 이동하고 복구 솔루션의 필요성 파악 

Diamond Tools는 클라우드 스토리지 서비스 인 Amazon EC2 및 Amazon S3를 구현했습니다. 그들은 그룹웨어, 영업 지원 및 화상 회의 시스템을 AWS로 옮겼습니다.  Diamond Tools의 화상 회의 시스템은 일상 업무에 매우 중요합니다.  “다양한 회의 및 해외 지역과의 회의에서 매우 자주 사용되는 도구입니다.  한 달에 약 100 번 사용되며, 기존 SaaS SaaS 시스템에서 AWS로 전환함으로써 연간 2 백만 엔의 비용을 줄일 수있었습니다.”라고 Kokubo는 말합니다.  이전에는 다른 회사를 포함하여 너무 많은 사용자가 동시에 시스템에 연결된 경우 음질이 저하되었습니다.  그런 다음 Kokubo는 사용자로부터 불만을 접수하지만 문제를 쉽게 해결할 수 없었습니다.  AWS에서 회사 별 화상 회의 시스템을 구축하면 비디오 및 오디오 품질이 안정화되고 불만이 줄어 듭니다.

Kokubo는 곧 EC2 환경과 관련된 문제를 경험했습니다. “EC2는 인프라로서 안정적입니다. 그러나 때때로 서비스가 실패합니다. 나는 항상 걱정했고 어느 날 해외 출장 중에 사용자가 시스템에 액세스 할 수 없다는 전화를 받았습니다.  VPN을 통해 AWS에 연결하고 실패한 서비스를 복구하기 위해 항상 가지고 다니는 랩탑을 열어야했습니다.”라고 Kokubo는 말했습니다.  분명히이 프로세스는 확장 할 수 없었습니다.

그룹웨어 응용 프로그램이 실행 된 인스턴스에서 서비스 오류가 자주 발생했습니다.  회사 직원의 대부분은 매일 아침 그룹웨어 응용 프로그램을 사용하여 일정을 확인하거나 회의실을 예약합니다. Kokubo는“많은 사람들이 저에게 전화를 걸어 문제가 발생한 경우 어떤 일이 있었는지 묻습니다. 그는이 경험을 통해 스스로 시스템을 관리하는 위험을 배웠습니다.

“10 년 전에는 장애가 발생했을 때 시스템이 중단되어 사용자가 익숙해졌습니다. 그러나 오늘은 문제가 발생하자마자 불만을 접수합니다. 이제 시스템은 언제라도 수돗물에서 나오는 물처럼 항상 작동하고 작동해야합니다.  시스템 가동 중지 시간이 점점 더 감당할 수 없게되었습니다.”라고 Kokubo는 말했습니다.

Kokubo는 EC2에서 실행되는 서비스 중 하나가 실패했을 때 항상 모든 문제를 처리해야한다고 느꼈습니다.  모든 문제를 해결할 수있는 유일한 사람이 된 것은 그에게 계속 부담이되었습니다.  Kokubo는“1 인 IT 샵이므로 헬프 데스크 기능 만 제공하는 것이 저의 가치라고 생각하는 경향이 있습니다.  그러나 좋지 않습니다. 도쿄 다이아몬드 시스템을 어떻게 지원하지 않고 작동시킬 수 있는지 고려해야했습니다.”

클라우드 서비스에 더 의존하는 회사의 유일한 IT 전문가 였기 때문에 도움이 필요하다는 것을 알았습니다. “Sony Network Communications가 SIOS AppKeeper가 EC2 인스턴스의 자동화 된 운영 및 관리를 제공한다고 말했을 때, 나는 세부 사항을 살펴보기 전에도이를 사용하기로 결정했습니다. EC2 서비스를 자동으로 복구하는 솔루션이 있다면 이동 중에 VPN에 연결하여 모든 문제를 해결할 필요가 없습니다.”라고 Kokubo는 덧붙였습니다.

SIOS AppKeeper는 EC2 인스턴스를 모니터링하고 시스템 장애가 감지되면 서비스를 자동으로 다시 시작하는 클라우드 서비스입니다.  모니터링되는 서비스가 실패 할 경우 SIOS AppKeeper는 직원이 수동으로 개입하지 않아도 서비스를 자동으로 복구합니다.

AWS에서 실행되는 10 개 이상의 애플리케이션

도쿄 다이아몬드는 다른 애플리케이션을 계속 AWS로 마이그레이션했으며, 2018 년 6 월까지 AWS에서 10 개 이상의 애플리케이션이 실행되고있었습니다. “AWS가 유용하다고 생각합니다. 운영 체제는 10 분 안에 시작되며 비즈니스에 따라 유연하게 리소스를 확장 / 축소 할 수 있습니다. 작동하지 않더라도 리소스를 삭제할 수도 있습니다.  그러나 대량의 데이터를 처리하는 핵심 시스템은 AWS가 아닌 데이터 센터를 사용하여 가상 환경으로 마이그레이션되었습니다.  우리는 사용량과 요구에 따라 시스템을 구축하기 위해 AWS와 가상 데이터 센터를 모두 사용하고 있습니다.”라고 Kokubo는 말했습니다.

도쿄 다이아몬드는 현재 직원들이 그룹웨어 애플리케이션, 영업 자동화 및 화상 회의 시스템을 포함하여 AppKeeper에 의존하는 3 가지 중요한 애플리케이션을 모니터링합니다.  Kokubo는“먼저 우리는 응용 프로그램을 분류하고 그 중 세 가지로 시작하기로 결정했습니다. 출장 중에 일상적인 정신적 부담에서 벗어나 마음의 평안을 얻을 수 있다면 비용을 지불 할 가치가 있습니다.”

SIOS AppKeeper, IT 직원이 다른 작업에 집중할 수 있도록 지원

Kokubo 씨에 따르면 더 이상 AppKeeper가 모니터링하는 인스턴스의 운영 및 관리에 대해 생각할 필요가 없습니다.  AppKeeper는 완벽하게 작동합니다.  가상 머신과 다른 AWS 애플리케이션에 집중할 시간이 생겼습니다.  Kokubo는 AppKeeper가 이러한 핵심 응용 프로그램에 대한 보안을 제공한다고 생각합니다.

그러나 AppKeeper에 대한 SIOS 기술 개발 팀에 대한 요청이 있습니다.  “이벤트가 없으면 제대로 작동하는지 걱정이되거나 로그인 방법을 잊어 버릴 수 있습니다. 그것이 작동하고 있다는 사실을 자주 나에게 알려 주면 더 좋을 것입니다.”라고 Kokubo는 말했습니다.  자동 운영 및 관리는 SIOS AppKeeper의 강점입니다. 그러나 아무 일도 일어나지 않으면 보이지 않을 수 있습니다.

Kokubo는 이러한 응용 프로그램의 문제를 해결할 필요가 없다는 점에 동의합니다.  이제 그는 진화하는 Diamond Tool의 IT 전략 및 계획, 보안 및 BCP 이니셔티브를 포함하여 관리에 더 많은 시간을 할애 할 수 있습니다.

오늘날 Diamond Tool은 세 가지 응용 프로그램의 운영 및 관리에 SIOS AppKeeper를 사용하지만 AppKeeper의 적용 범위를 다른 응용 프로그램으로 곧 확장 할 계획입니다.  이를 통해 Kokubo는 이러한 부가 가치 활동에 많은 시간을 할애 할 수 있습니다.  “직원을 고용하려고해도 일본의 인력이 줄어들 기 때문에 어렵다.  미래에는 AI (Artificial Intelligence)를 사용하는 사람들을 대체 할 시스템 툴이 필요하며 SIOS AppKeeper가 AI와 같은 기능을 개발하여 고 충격 장애를 자동으로 해결하기를 희망합니다.”라고 덧붙였습니다. 운영 관리의 실현.

SIOS AppKeeper에 대해 더 알아보기

SIOS AppKeeper 무료 평가판 가입

 

 

기업 가용성 : 법원의 교훈

기업 가용성 : 법원의 교훈

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

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

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

구성 유연성

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

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

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

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

주요 혜택

방재

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

적응성

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

사용의 용이성

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

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