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 9월 2021

Huawei 클라우드에 SQL Server 장애 조치 클러스터 인스턴스 배포

9월 28, 2021 by Jason Aw Leave a Comment

화웨이 클라우드 고가용성 ECS IaaS

* 면책 조항: 다음은 당사 제품 범위 내에서 고가용성 부분을 완전히 다루지만 이것은 설정 “가이드”일 뿐이며 사용자 고유의 구성에 맞게 조정해야 합니다.

개요 화웨이 클라우드 는 중국뿐만 아니라 전 세계에 많은 데이터 센터가 있는 글로벌 기반을 갖춘 선도적인 클라우드 서비스 제공업체입니다. 그들은 ICT 인프라 제품 및 솔루션에 대한 화웨이의 30년 이상의 전문 지식을 결합하고 애플리케이션을 강화하고 데이터의 힘을 활용하며 오늘날 모든 규모의 조직이 성장하도록 돕기 위해 안정적이고 안전하며 비용 효율적인 클라우드 서비스를 제공하기 위해 최선을 다하고 있습니다. 지적인 세계. HUAWEI CLOUD는 또한 기술 혁신을 통해 저렴하고 효과적이고 안정적인 클라우드 및 AI 서비스를 제공하기 위해 노력하고 있습니다.

DataKeeper Cluster Edition은 Huawei 클라우드의 가용 영역 전반에 걸쳐 단일 지역 내의 가상 사설 클라우드(VPC)에서 복제를 제공합니다. 이 특정 SQL Server 클러스터링 예제에서는 4개의 인스턴스(도메인 컨트롤러 인스턴스 1개, SQL Server 인스턴스 2개 및 쿼럼/감시 인스턴스 1개)를 3개의 가용성 영역으로 시작합니다.

Huawei Cloud SIOS Datakeeper HA 아키텍처

DataKeeper Cluster Edition은 Huawei 클라우드의 모든 노드와 함께 클러스터 외부의 데이터 복제 노드를 지원합니다. 이 특정 SQL Server 클러스터링 예제에서는 4개의 인스턴스(도메인 컨트롤러 인스턴스 1개, SQL Server 인스턴스 2개 및 쿼럼/감시 인스턴스 1개)가 3개의 가용성 영역으로 시작됩니다. 그런 다음 두 지역의 VPN 인스턴스를 포함하여 두 번째 지역에서 추가 DataKeeper 인스턴스가 시작됩니다. 봐주세요 클러스터 노드에서 외부 DR 사이트로 데이터 복제 구성 자세한 내용은. 여러 지역 사용에 대한 추가 정보는 다음을 참조하십시오. 서로 다른 지역에 있는 두 VPC 연결 .

Huawei Cloud SIOS Datakeeper DR 아키텍처

DataKeeper Cluster Edition은 또한 Huawei Cloud의 클러스터 외부에 있는 노드만 있는 클러스터 외부의 데이터 복제 노드에 대한 지원을 제공합니다. 이 특정 SQL Server 클러스터링 예제에서 WSFC1 및 WSFC2는 Huawei Cloud 인스턴스로 복제하는 온사이트 클러스터에 있습니다. 그런 다음 Huawei Cloud의 한 지역에서 추가 DataKeeper 인스턴스가 시작됩니다. 봐주세요 클러스터 노드에서 외부 DR 사이트로 데이터 복제 구성 자세한 내용은.

Huawei Cloud SIOS Datakeeper 하이브리드 DR 아키텍처

요구 사항

설명 요구 사항
가상 사설 클라우드 3개의 가용 영역이 있는 단일 지역에서
인스턴스 유형 최소 권장 인스턴스 유형: s3.large.2
운영 체제 DKCE 지원 매트릭스 보기
탄력적 IP 도메인 컨트롤러에 연결된 하나의 탄력적 IP 주소
4개의 인스턴스 도메인 컨트롤러 인스턴스 1개, SQL Server 인스턴스 2개 및 쿼럼/감시 인스턴스 1개
각 SQL 서버 4개의 IP가 있는 ENI(탄력적 네트워크 인터페이스) · Windows에서 정적으로 정의되고 DataKeeper Cluster Edition에서 사용되는 기본 ENI IP · Windows Failover Clustering, DTC 및 SQLFC에서 사용되는 동안 ECS에서 유지 관리하는 3개의 IP
볼륨 3개의 볼륨(EBS 및 NTFS만 해당) · 1개의 기본 볼륨(C 드라이브) · 2개의 추가 볼륨 o 장애 조치 클러스터링용 1개 o MSDTC용 1개

릴리즈 노트 시작하기 전에 DataKeeper 클러스터 에디션 출시 정보 최신 정보를 위해. 읽고 이해하는 것이 좋습니다. DataKeeper 클러스터 에디션 설치 가이드 .

가상 사설 클라우드(VPC) 생성 가상 사설 클라우드는 DataKeeper Cluster Edition을 사용할 때 생성하는 첫 번째 개체입니다.

* 가상 사설 클라우드(VPC)는 공용 클라우드에서 구성 가능한 공유 컴퓨팅 리소스 풀로 구성된 격리된 사설 클라우드입니다.

  1. 회원가입 시 지정한 이메일 주소와 비밀번호 사용 화웨이 클라우드 , 로그인 화웨이 클라우드 관리 콘솔 .
  2. 로부터 서비스 드롭다운, 선택 가상 사설 클라우드 .

  1. 화면 오른쪽에서 다음을 클릭합니다. VPC 생성 사용하려는 지역을 선택합니다.
  2. VPC에 사용할 이름을 입력하십시오.
  3. 다음을 입력하여 가상 사설 클라우드 서브넷을 정의합니다. CIDR(클래스 없는 도메인 간 라우팅) 아래에 설명된 대로
  4. 서브넷 이름을 입력한 다음 클릭 지금 만들기 .

* 새 VPC에 대한 “기본” 연결을 사용하여 라우팅 테이블이 자동으로 생성됩니다. 나중에 사용하거나 다른 라우팅 테이블을 생성할 수 있습니다.

* 유용한 링크: 화웨이의 가상 사설 클라우드(VPC) 생성 인스턴스 시작 다음은 서브넷으로 인스턴스를 시작하는 과정을 안내합니다. 두 개의 인스턴스를 하나의 가용성 영역으로 시작하려고 할 것입니다. 하나는 도메인 컨트롤러 인스턴스용이고 다른 하나는 SQL 인스턴스용입니다. 그런 다음 다른 가용 영역으로 다른 SQL 인스턴스를 시작하고 또 다른 가용 영역으로 쿼럼 감시 인스턴스를 시작합니다.

* 유용한 링크: 화웨이 클라우드 ECS 인스턴스

  1. 회원가입 시 지정한 이메일 주소와 비밀번호 사용 화웨이 클라우드 , 로그인 화웨이 클라우드 관리 콘솔 .
  2. 로부터 서비스 목록 드롭다운, 선택 탄력적 클라우드 서버 .

  1. 선택하다 ECS 구매 버튼을 누르고 결제 모드, 리전 및 AZ(가용 영역)를 선택하여 인스턴스를 배포합니다.
  2. 인스턴스 유형을 선택합니다. ( 메모: s3.large.2 이상을 선택하십시오.).
  3. 이미지를 선택합니다. 공개 이미지에서 Windows Server 2019 데이터 센터 64비트 영어 영상
    1. 을위한 네트워크 구성 , VPC를 선택하십시오.
    2. 을위한 서브넷 , 사용하려는 서브넷을 선택하고 수동으로 지정한 IP 주소 사용하려는 IP 주소를 입력하십시오.
    3. 선택 보안 그룹 사용하거나 기존 것을 편집하고 선택합니다.
    4. EIP 할당 인터넷에 액세스하기 위해 ECS 인스턴스가 필요한 경우
    5. 딸깍 하는 소리 고급 설정 구성 ECS의 이름을 제공하고 비밀번호 ~을위한 로그인 모드 관리자 로그인을 위한 보안 암호 제공
    6. 딸깍 하는 소리 지금 구성 ~에 고급 옵션 을 추가하다 꼬리표 인스턴스 이름을 지정하고 확인하다
  4. 인스턴스의 최종 검토를 수행하고 제출하다 .

* 중요한: 이 초기 관리자 암호를 기록해 두십시오. 인스턴스에 로그온하는 데 필요합니다.

모든 인스턴스에 대해 위의 단계를 반복합니다.

인스턴스에 연결 다음을 통해 도메인 컨트롤러 인스턴스에 연결할 수 있습니다. 원격 로그인 ECS 창에서.

관리자로 로그인하고 다음을 입력하십시오. 관리자 비밀번호 .

* 모범 사례: 로그인한 후에는 비밀번호를 변경하는 것이 가장 좋습니다.

도메인 컨트롤러 인스턴스 구성 이제 인스턴스가 생성되었으므로 도메인 서비스 인스턴스 설정을 시작했습니다.

이 가이드는 Active Domain 서버 인스턴스를 설정하는 방법에 대한 자습서가 아닙니다. 읽기를 권장합니다 조항 Active Directory 서버를 설정하고 구성하는 방법에 대해 설명합니다. 인스턴스가 Huawei 클라우드에서 실행 중이더라도 이것은 Active Directory의 일반 설치임을 이해하는 것이 매우 중요합니다.

고정 IP 주소 인스턴스에 대한 고정 IP 주소 구성

  1. 도메인 컨트롤러 인스턴스에 연결합니다.
  2. 딸깍 하는 소리 시작 / 제어판 .
  3. 딸깍 하는 소리 네트워크 및 공유 센터 .
  4. 네트워크 인터페이스를 선택하십시오.
  5. 딸깍 하는 소리 속성 .
  6. 딸깍 하는 소리 인터넷 프로토콜 버전 4(TCP/IPv4) , 그 다음에 속성 .
  7. 현재 얻기 IPv4 주소 , 기본 게이트웨이 그리고 DNS 서버 네트워크 인터페이스의 경우 아마존 .
  8. 에서 인터넷 프로토콜 버전 4(TCP/IPv4) 속성 대화 상자, 아래 다음 IP 주소 사용 , 귀하의 IPv4 주소 .
  9. 에서 서브넷 마스크 상자에 가상 사설 클라우드 서브넷과 연결된 서브넷 마스크를 입력합니다.
  10. 에서 기본 게이트웨이 상자에 입력 IP 주소 기본 게이트웨이의 다음을 클릭합니다. 좋아요 .
  11. 를 위해 선호하는 DNS 서버 , 들어가다 도메인 컨트롤러의 기본 IP 주소 (예: 15.0.1.72).
  12. 딸깍 하는 소리 괜찮아 , 선택 닫다 . 출구 네트워크 및 공유 센터 .
  13. 다른 인스턴스에서 위의 단계를 반복합니다.

두 개의 SQL 인스턴스와 증인 인스턴스를 도메인에 조인 * 도메인에 가입하기 전에 이러한 네트워크 조정을 수행하십시오. 네트워크 어댑터에서 기본 설정 DNS 서버를 새 도메인 컨트롤러 주소와 해당 DNS 서버로 추가/변경합니다. 이 변경 후 DNS 검색 목록을 새로 고치려면 ipconfig /flushdns를 사용하십시오. 도메인 가입을 시도하기 전에 이 작업을 수행하십시오.

* 다음을 확인하십시오. 핵심 네트워킹 그리고 파일 및 프린터 공유 옵션은 Windows 방화벽에서 허용됩니다.

  1. 각 인스턴스에서 시작 을 클릭한 다음 마우스 오른쪽 버튼을 클릭합니다. 컴퓨터 그리고 선택 속성 .
  2. 맨 오른쪽에서 설정 변경 .
  3. 클릭 변화 .
  4. 새로 입력 컴퓨터 이름 .
  5. 선택하다 도메인 .
  6. 입력하다 도메인 이름 – (예: docs.huawei.com).
  7. 딸깍 하는 소리 적용하다 .

* 사용하다 제어판 모든 인스턴스가 해당 위치에 올바른 시간대를 사용하고 있는지 확인합니다.

* 모범 사례: 시스템 페이지 파일을 다음으로 설정하는 것이 좋습니다. 시스템 관리 (자동이 아님) 항상 C: 드라이브를 사용합니다.

제어판 > 고급 시스템 설정 > 성능 > 설정 > 고급 > 가상 메모리. 선택하다 시스템 관리 크기 , 볼륨 C: 만 선택한 다음 세트 저장합니다.

두 개의 SQL 인스턴스에 보조 프라이빗 IP 할당 기본 IP 외에도 각 SQL 인스턴스의 탄력적 네트워크 인터페이스에 3개의 추가 IP(보조 IP)를 추가해야 합니다.

  1. 로부터 서비스 목록 드롭다운, 선택 탄력적 클라우드 서버 .
  2. 보조 사설 IP 주소를 추가하려는 인스턴스를 클릭합니다.
  3. 선택하다 NIC > 가상 IP 주소 관리 .
  4. 클릭 가상 IP 주소 할당 그리고 선택 설명서 인스턴스의 서브넷 범위 내에 있는 IP 주소를 입력합니다(예: 15.0.1.25의 경우 15.0.1.26을 입력합니다. 딸깍 하는 소리 확인 .
  5. 클릭 더 IP 주소 행에서 드롭다운을 선택하고 서버에 바인딩 , IP 주소를 바인딩할 서버와 NIC 카드를 선택합니다.
  6. 딸깍 하는 소리 좋아요 작업을 저장합니다.
  7. 에서 위의 작업을 수행합니다. 두 SQL 인스턴스 .

* 유용한 링크: 가상 IP 주소 관리 가상 IP 주소를 EIP 또는 ECS에 바인딩 볼륨 생성 및 연결 DataKeeper는 블록 수준 볼륨 복제 솔루션이며 클러스터의 각 노드에는 크기와 드라이브 문자가 동일한 추가 볼륨(시스템 드라이브 제외)이 있어야 합니다. 검토하시기 바랍니다 볼륨 고려 사항 저장 요구 사항에 대한 추가 정보는

볼륨 생성 각 SQL Server 인스턴스에 대해 각 가용성 영역에 2개의 볼륨을 생성하여 총 4개의 볼륨을 생성합니다.

  1. 로부터 서비스 목록 드롭다운, 선택 탄력적 클라우드 서버 .
  2. 관리하려는 인스턴스를 클릭합니다.
  3. 로 이동 디스크 탭
  4. 딸깍 하는 소리 디스크 추가 원하는 크기와 크기의 새 볼륨을 추가하려면 볼륨을 연결할 SQL 서버와 동일한 AZ에 있는 볼륨을 선택해야 합니다.
  5. SLA에 동의하는 확인란을 선택하고 제출하다
  6. 딸깍 하는 소리 서버 콘솔로 돌아가기
  7. 붙이다 SQL 인스턴스에 필요한 경우 디스크
  8. 네 권 모두에 대해 이 작업을 수행합니다.

* 유용한 링크: 탄력적 볼륨 서비스 클러스터 구성 DataKeeper Cluster Edition을 설치하기 전에 노드 과반수 쿼럼(노드 수가 홀수인 경우) 또는 노드 및 파일 공유 과반수 쿼럼(짝수가 있는 경우)을 사용하여 Windows Server를 클러스터로 구성하는 것이 중요합니다. 노드). 단계별 지침은 이 항목 외에 클러스터링에 대한 Microsoft 설명서를 참조하십시오.메모: 마이크로소프트가 발표한 핫픽스 특정 다중 사이트 클러스터 구성에서 더 높은 수준의 가용성을 달성하는 데 도움이 될 수 있는 노드의 투표를 비활성화할 수 있는 Windows 2008R2용.

장애 조치 클러스터링 추가 두 SQL 인스턴스에 장애 조치 클러스터링 기능을 추가합니다.

  1. 시작하다 서버 매니저 .
  2. 선택하다 특징 왼쪽 창에서 기능 추가 에서 특징 이것은 시작 기능 추가 마법사 .
  3. 선택하다 장애 조치 클러스터링 .
  4. 선택하다 설치 .

구성 검증

  1. 열려있는 장애 조치 클러스터 관리자 .
  2. 장애 조치(Failover) 클러스터 관리자를 선택하고 구성 검증 .
  3. 딸깍 하는 소리 다음 , 다음 두 개를 추가하십시오 SQL 인스턴스 .

메모: 검색하려면 다음을 선택하십시오. 검색 을 클릭한 다음 고급의 그리고 지금 찾기 . 사용 가능한 인스턴스가 나열됩니다.

  1. 딸깍 하는 소리 다음 .
  2. 선택하다 내가 선택한 테스트만 실행 클릭 다음 .
  3. 에서 테스트 선택 화면, 선택 해제 저장 클릭 다음 .
  4. 결과 확인 화면에서 다음 .
  5. 검토 검증 요약 보고서 그런 다음 클릭 마치다 .

클러스터 생성

  1. 에 장애 조치 클러스터 관리자 , 클릭 클러스터 생성 그런 다음 클릭 다음 .
  2. 두 개를 입력하세요 SQL 인스턴스 .
  3. 에 검증 경고 페이지, 선택 아니요 그런 다음 클릭 다음 .
  4. 에 클러스터 관리를 위한 액세스 포인트 페이지에서 WSFC 클러스터의 고유한 이름을 입력합니다. 그런 다음 입력 장애 조치 클러스터링 IP 주소 클러스터에 관련된 각 노드에 대해 이것은 3가지 중 첫 번째 보조 IP 주소 각 인스턴스에 이전에 추가되었습니다.
  5. 중요! “클러스터에 사용 가능한 모든 스토리지 추가” 확인란의 선택을 취소하십시오. DataKeeper 미러링 드라이브는 기본적으로 클러스터에서 관리하면 안 됩니다. DataKeeper 볼륨으로 관리됩니다.
  6. 딸깍 하는 소리 다음 에 확인
  7. 에 요약 페이지에서 경고를 검토한 다음 선택 마치다 .

쿼럼/감시 구성

  1. 쿼럼/감시 인스턴스(감시)에 폴더를 만듭니다.
  2. 폴더를 공유합니다.
    1. 폴더를 마우스 오른쪽 버튼으로 클릭하고 선택 공유/특정 사람들과 공유 ….
    2. 드롭다운에서 모든 사람 클릭 추가하다 .
    3. 아래에 권한 수준 , 선택하다 읽기/쓰기 .
    4. 딸깍 하는 소리 공유하다 , 그 다음에 완료 . (아래에서 사용할 이 파일 공유의 경로를 기록해 두십시오.)
  3. 에 장애 조치 클러스터 관리자 , 클러스터를 마우스 오른쪽 버튼으로 클릭하고 더 많은 행동 그리고 클러스터 쿼럼 설정 구성 . 딸깍 하는 소리 다음 .
  4. 에 쿼럼 구성 선택 , 선택하다 노드 및 파일 공유 과반수 클릭 다음 .
  5. 에 파일 공유 감시 구성 화면에서 이전에 생성한 파일 공유 경로를 입력하고 다음 .
  6. 에 확인 페이지, 클릭 다음 .
  7. 에 요약 페이지, 클릭 마치다 .

DataKeeper 설치 및 구성 기본 클러스터가 구성된 후 클러스터 리소스가 생성되기 전에 설치하고 라이선스를 부여합니다. DataKeeper 클러스터 에디션 모든 클러스터 노드에서. 참조 DataKeeper 클러스터 에디션 설치 가이드 자세한 지침은.

  1. 운영 데이터 키퍼 설정 설치하기 위해서 DataKeeper 클러스터 에디션 두 SQL 인스턴스 모두에서.
  2. 귀하의 라이센스 키 메시지가 표시되면 재부팅합니다.
  3. 시작 데이터키퍼 GUI 그리고 서버에 연결 .

* 메모 : 사용된 도메인 또는 서버 계정은 로컬 시스템 관리자 그룹에 추가되어야 합니다. 계정에는 DataKeeper가 설치된 각 서버에 대한 관리자 권한이 있어야 합니다. 인용하다 DataKeeper 서비스 로그온 ID 및 비밀번호 선택 추가 정보를 위해.

  1. 오른쪽 클릭 채용정보 두 SQL 서버에 모두 연결합니다.
  2. 작업 만들기 생성할 각 미러에 대해 하나는 DTC 리소스용이고 다른 하나는 SQL 리소스용입니다.
  3. 볼륨을 클러스터 볼륨으로 자동 등록할지 묻는 메시지가 표시되면 예 .

* 메모: Windows “Core”(GUI가 없는 Windows)에 DataKeeper Cluster Edition을 설치하는 경우 다음을 읽으십시오. Windows 2008R2/2012 Server Core 플랫폼에 DataKeeper 설치 및 사용 자세한 지침은.

MSDTC 구성

  1. Windows Server 2012 및 2016의 경우 장애 조치 클러스터 관리자 GUI , 선택하다 역할 , 선택 역할 구성 .
  2. 선택하다 분산 트랜잭션 코디네이터(DTC) , 클릭 다음 .

* Windows Server 2008의 경우 장애 조치 클러스터 관리자 GUI , 선택하다 서비스 및 애플리케이션 , 선택 서비스 또는 애플리케이션 구성 클릭 다음 .

  1. 에 클라이언트 액세스 포인트 화면에서 이름을 입력한 다음 MSDTC IP 주소 클러스터에 관련된 각 노드에 대해 이것은 셋 중 두 번째다. 보조 IP 주소 각 인스턴스에 이전에 추가되었습니다. 딸깍 하는 소리 다음 .
  2. 선택 MSDTC 볼륨 클릭 다음 .
  3. 에 확인 페이지, 클릭 다음 .
  4. 일단 요약 페이지 표시, 클릭 마치다 .

첫 번째 SQL 인스턴스에 SQL 설치

  1. 도메인 컨트롤러 서버에서 폴더를 만들고 공유합니다..
    1. 예를 들어 모든 사람 권한이 있는 “TEMPSHARE”입니다.
  2. “SQL” 하위 폴더를 만들고 SQL .iso 설치 프로그램을 해당 하위 폴더에 복사합니다.
  3. SQL 서버에서 네트워크 드라이브를 만들고 도메인 컨트롤러의 공유 폴더에 연결합니다.
    • . 예: “net use S: \TEMPSHARE
  4. SQL 서버에 S: 드라이브가 나타납니다. CD를 SQL 폴더에 넣고 SQL .iso 설치 프로그램을 찾습니다. .iso 파일을 마우스 오른쪽 버튼으로 클릭하고 산 . setup.exe 설치 프로그램이 SQL .iso 설치 프로그램과 함께 나타납니다.

F:>설정 /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster

  1. 에 지원 규칙 설정 , 클릭 좋아요 .
  2. 에 제품 키 대화 상자에서 제품 키 클릭 다음 .
  3. 에 라이선스 조건 대화 상자, 수락 라이센스 계약 클릭 다음 .
  4. 에 제품 업데이트 대화 상자, 클릭 다음 .
  5. 에 설정 지원 파일 대화 상자, 클릭 설치 .
  6. 에 지원 규칙 설정 대화 상자에서 경고를 받게 됩니다. 딸깍 하는 소리 다음 , 이 메시지는 다중 사이트 또는 비공유 스토리지 클러스터에서 예상되므로 무시합니다.
  7. 검증 클러스터 노드 구성 클릭 다음 .
  8. 구성 클러스터 네트워크 SQL 인스턴스에 대한 “세 번째” 보조 IP 주소를 추가하고 다음 . 딸깍 하는 소리 예 다중 서브넷 구성을 진행합니다.
  9. 입력하다 비밀번호 서비스 계정에 대해 클릭하고 다음 .
  10. 에 오류 보고 대화 상자, 클릭 다음 .
  11. 에 노드 규칙 추가 대화 상자에서 건너뛴 작업 경고는 무시할 수 있습니다. 딸깍 하는 소리 다음 .
  12. 기능 확인 및 클릭 설치 .
  13. 딸깍 하는 소리 닫다 설치 프로세스를 완료합니다.

두 번째 SQL 인스턴스에 SQL 설치 두 번째 SQL 인스턴스를 설치하는 것은 첫 번째 인스턴스와 유사합니다.

  1. SQL 서버에서 네트워크 드라이브를 만들고 첫 번째 SQL 서버에 대해 위에서 설명한 대로 도메인 컨트롤러의 공유 폴더에 연결합니다.
  2. .iso 설치 프로그램이 마운트되면 다음을 실행하십시오. SQL 설정 건너 뛰기 위해 명령 줄에서 다시 한 번 확인 열기 명령 창에서 귀하의 SQL 설치 디렉토리 다음 명령을 입력하십시오.

설정 /SkipRules=Cluster_VerifyForErrors /Action=AddNode /INSTANCENAME=”MSSQLSERVER”( 메모 : 이것은 첫 번째 노드에 기본 인스턴스를 설치했다고 가정합니다)

  1. 에 지원 규칙 설정 , 클릭 좋아요 .
  2. 에 제품 키 대화 상자에서 제품 키 클릭 다음 .
  3. 에 라이선스 조건 대화 상자, 수락 라이센스 계약 클릭 다음 .
  4. 에 제품 업데이트 대화 상자, 클릭 다음 .
  5. 에 설정 지원 파일 대화 상자, 클릭 설치 .
  6. 에 지원 규칙 설정 대화 상자에서 경고를 받게 됩니다. 딸깍 하는 소리 다음 , 이 메시지는 다중 사이트 또는 비공유 스토리지 클러스터에서 예상되므로 무시합니다.
  7. 검증 클러스터 노드 구성 클릭 다음 .
  8. 구성 클러스터 네트워크 SQL 인스턴스에 대한 “세 번째” 보조 IP 주소를 추가하고 다음 . 딸깍 하는 소리 예 다중 서브넷 구성을 진행합니다.
  9. 입력하다 비밀번호 서비스 계정에 대해 클릭하고 다음 .
  10. 에 오류 보고 대화 상자, 클릭 다음 .
  11. 에 노드 규칙 추가 대화 상자에서 건너뛴 작업 경고는 무시할 수 있습니다. 딸깍 하는 소리 다음 .
  12. 기능 확인 및 클릭 설치 .
  13. 딸깍 하는 소리 닫다 설치 프로세스를 완료합니다.

공통 클러스터 구성 이 섹션에서는 다음을 설명합니다. 일반적인 2노드 복제 클러스터 구성 .

  1. 초기 구성은 다음에서 수행해야 합니다. 데이터키퍼 UI 클러스터 노드 중 하나에서 실행 중입니다. Windows Core 전용 서버에서 DataKeeper를 실행할 때와 같이 클러스터 노드에서 DataKeeper UI를 실행할 수 없는 경우 Windows XP 이상을 실행하는 컴퓨터에 DataKeeper UI를 설치하고 다음 지침을 따르십시오. 코어만 미러를 만들고 명령줄을 통해 클러스터 리소스를 등록하는 섹션을 참조하세요.
  2. DataKeeper UI가 실행되면 각 노드에 연결 클러스터에서.
  3. 작업 만들기 DataKeeper UI를 사용하여 이 프로세스는 미러를 만들고 사용 가능한 저장소에 DataKeeper 볼륨 리소스를 추가합니다.

! 중요한: 확인 가상 네트워크 이름 ~을위한 NIC 연결 모든 클러스터 노드에서 동일합니다.

  1. 추가 미러가 필요한 경우 다음을 수행할 수 있습니다. 작업에 미러 추가 .
  2. 이랑 DataKeeper 볼륨 지금에 사용 가능한 스토리지 , 클러스터에 공유 디스크 리소스가 있는 것과 동일한 방식으로 클러스터 리소스(SQL, 파일 서버 등)를 생성할 수 있습니다. 위의 단계별 클러스터 구성 지침 외에 추가 정보는 Microsoft 설명서를 참조하십시오.

클러스터(가상) IP에 대한 연결 기본 IP 및 보조 IP 외에도 Huawei Cloud에서 가상 IP 주소를 구성하여 활성 노드로 라우팅할 수 있도록 해야 합니다.

  1. 로부터 서비스 목록 드롭다운, 선택 탄력적 클라우드 서버 .
  2. 클러스터 가상 IP 주소를 추가하려는 SQL 인스턴스 중 하나를 클릭합니다(MSDTC용 하나, SQL 장애 조치 클러스터용 하나).
  3. 선택하다 NIC > 가상 IP 주소 관리 .
  4. 클릭 가상 IP 주소 할당 그리고 선택 설명서 인스턴스의 서브넷 범위 내에 있는 IP 주소를 입력합니다(예: 15.0.1.25의 경우 15.0.1.26을 입력합니다. 딸깍 하는 소리 확인 .
  5. 클릭 더 IP 주소 행에서 드롭다운을 선택하고 서버에 바인딩 , IP 주소를 바인딩할 서버와 NIC 카드를 모두 선택합니다.
  6. MSDTC 및 SQLFC 가상 IP에 대해 동일한 4. 및 5단계를 사용합니다.
  7. 딸깍 하는 소리 좋아요 작업을 저장합니다.

관리 DataKeeper 볼륨이 Windows Server 장애 조치 클러스터링에 등록되면 해당 볼륨의 모든 관리는 Windows Server 장애 조치 클러스터링 인터페이스를 통해 수행됩니다. DataKeeper에서 일반적으로 사용 가능한 모든 관리 기능 비활성화됩니다 클러스터 제어하에 있는 모든 볼륨에서. 대신 DataKeeper 볼륨 클러스터 리소스가 미러 방향을 제어하므로 DataKeeper 볼륨이 노드에서 온라인 상태가 되면 해당 노드가 미러 소스가 됩니다. DataKeeper Volume 클러스터 리소스의 속성은 미러의 소스, 대상, 유형 및 상태와 같은 기본 미러링 정보도 표시합니다.

문제 해결 다음 리소스를 사용하여 문제를 해결하세요.

  • 문제 해결 문제 섹션
  • 지원 계약을 맺은 고객의 경우 – http://us.sios.com/support/overview/
  • 평가판 고객 전용 – 사전 판매 지원

추가 리소스: 단계별: Windows Server 2008 R2에서 2노드 다중 사이트 클러스터 구성 – 1부 — http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93 -1 부/ 단계별: Windows Server 2008 R2에서 2노드 다중 사이트 클러스터 구성 – 파트 3 — http://clusteringformeremortals.com/2009/10/07/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93 -파트-3/

Filed Under: Datakeeper, 서버 클러스터 단순화 Tagged With: SQL Server 장애 조치 (failover) 클러스터

시작을 잘하는 것도 좋지만 가동 시간을 유지하려면 주의가 필요합니다

9월 28, 2021 by Jason Aw Leave a Comment

시작을 잘하는 것도 좋지만 가동 시간을 유지하려면 주의가 필요합니다

 

 

시작을 잘하는 것도 좋지만 가동 시간을 유지하려면 주의가 필요합니다

작가 이사벨라 포레시스(Isabella Poretsis)는 “무엇인가를 시작하는 것은 쉬울 수 있지만, 그것을 끝내는 것이 가장 큰 장애물입니다.”라고 말합니다. 시작 회의를 하는 것이 좋습니다.상쾌하고 흥미진진합니다. 관리자와 리더는 설렘과 낙관으로 그린필드를 바라보고 있습니다.그러나 이 시작의 순간, 성공적인 배치의 샴페인 터지는 순간조차도 시작에 불과합니다. 가동 시간을 유지하려면 지속적인 주의가 필요합니다.

중요한 애플리케이션과 데이터베이스에 대한 고가용성과 99.9999%의 가동 시간은 일시적인 것이 아니라 포도원을 파괴하는 작은 여우를 없애기 위한 끊임없는 노력입니다.위협에 뒤처지지 않고 최신 업데이트를 유지하며 적절하게 훈련되고 준비되는 것은 귀하의 팀이 "휴가를 가질 자격이 없는" 작업입니다.

가동 시간 유지에 주의를 기울이고자 하는 사람들을 위해 다음 5가지 팁을 제공합니다.

1. 환경 모니터링

엔터프라이즈 소프트웨어에서는 여전히 "설정하고 잊어버리십시오"라는 사고방식을 따르는 경우가 거의 없습니다.그랜드 오프닝 샴페인의 코르크 마개를 푼 날부터 지금까지 모든 것이 쇠퇴의 상태로 나아가고 있습니다.서버, 워크로드, 네트워크 트래픽 및 하드웨어(가상 또는 물리적)를 모니터링하지 않으면 가동 시간과 안정성을 잃을 수 있습니다.

2. 유지 보수 수행

20년이 넘는 소프트웨어 개발 및 서비스에서 내가 항상 알아차린 한 가지는 모든 소프트웨어에는 업데이트가 함께 제공된다는 것입니다.적용합니다.백업 수행 및 확인을 포함하여 건전한 유지 관리 정책을 실행하는 것을 잊지 마십시오. 한 기술 작가는 당신이 후회하는 유일한 업데이트는 당신이 하지 못한 업데이트라고 제안했습니다.

3. 지속적으로 배우기

고가용성에 대한 나의 첫 소개는 CE-211 연구실에서 갓 나온 인턴으로 우리 연구실의 서버용 토큰 링의 한쪽 끝을 뽑았을 때였습니다.관리자는 몇 분 안에 내 얼굴에 있었다.귀를 기울이고 나서 그는 나에게 교육을 시켰다.이상적으로는 귀하와 귀하의 팀이 네트워크를 중단하지 않고 학습하기를 원하지만 계속 학습하기를 절대적으로 원합니다.기존 기술, 새로운 릴리스, 새로운 인프라에 대한 유료 과정을 살펴보십시오.프로세스, 환경, 소프트웨어 배포 및 회사 엔터프라이즈와 관련된 과정 및 항목에 대해 공급업체를 확인하십시오.돈이 문제라면 많은 것을 위한 무료 코스도 존재합니다.

4. 학습을 배가하라

지속적인 학습 외에도 학습을 배가할 계획을 세웁니다.SIOS의 고객 경험 부사장으로서 우리는 학습 내용을 공유하는 팀과 공유하지 않는 팀 간의 엄청난 차이를 보았습니다.학습을 공유하는 팀은 다운타임을 손상시키는 지식의 격차를 피합니다.당신이 무언가를 배웠다는 것을 아는 가장 좋은 방법은 그것을 다른 사람에게 가르치는 것입니다. 학습하는 동안 오류로 인한 가동 중지 시간의 위험을 줄이기 위해 팀 구성원과 학습 내용을 공유하고 그 문제에 대해서는 휴가를 제공합니다.

5. 잘 끝낸다. . .다음 시작 전에

모든 프로젝트, 서버 및 소프트웨어에는 끝이 있습니다.잘 끝내세요.올바르게 해제합니다.느슨한 끝을 닫고 잘 된 것과 그렇지 않은 것, 다음에 할 일을 문서화하여 다음 단계, 배포, 소프트웨어 관계 등을 잘 시작하십시오.기존 공급업체를 잘 대우하십시오.나중에 다시 필요할 수 있습니다.새 배포를 진행하기 전에 기존 시스템과 고가용성 솔루션을 이해합니다.이 적절한 결말은 더 나은 출발점에서 더 강한 결과를 향해 다시 시작하는 데 도움이 됩니다.

시스템을 고가용성으로 유지하는 것은 지속적인 프로세스입니다.설정하고 잊어버리면 좋은 캐치프레이즈이지만 가동 시간에는 경계, 지속적인 모니터링, 적절한 유지 관리 및 지속적이 필요하다는 것이 현실입니다.

-Cassius Rhue, VP, 고객 경험 복제 시오스

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

스플릿 브레인 시나리오 이해 및 피하기

9월 23, 2021 by Jason Aw Leave a Comment

스플릿 브레인 시나리오 이해 및 피하기

 

 

스플릿 브레인 시나리오 이해 및 피하기

분할 뇌. 우리 블로그의 대부분의 독자는 컴퓨팅 맥락에서 이 용어를 들어보았을 것입니다. 그러나 누군가가 두 개의 두뇌를 가지고 있고 둘 다 동등하게 제어할 수 있는 혼돈에 대한 첫 번째 정신적 이미지가 있는 사람들과 동정하지 않을 수 없습니다. 동시에.

장애 조치 클러스터 분할 브레인 시나리오란 무엇입니까?

장애 조치 클러스터 스플릿 브레인 시나리오에서 두 노드는 서로 통신할 수 없으며 대기 서버는 활성 노드가 실패했다고 생각하기 때문에 스스로를 활성 서버로 승격할 수 있습니다. 그 결과 두 노드가 모두 ‘활성’ 상태가 되어 서로가 실패한 것으로 간주됩니다. 결과적으로 두 노드의 데이터가 변경됨에 따라 데이터 무결성과 일관성이 손상됩니다. 이를 스플릿 브레인이라고 합니다.

적절한 조치를 취하지 않으면 SAP HANA 리소스 계층 구조에 대해 두 가지 유형의 분할 브레인 시나리오가 발생할 수 있습니다.

  • HANA 리소스 스플릿 브레인: HANA 리소스는 여러 클러스터 노드에서 활성(ISP)입니다. 이 상황은 일반적으로 클러스터 노드 간의 통신 경로에 영향을 미치는 일시적인 네트워크 중단으로 인해 발생합니다.
  • SAP HANA 시스템 복제 스플릿 브레인: HANA 리소스는 기본 노드에서 활성(ISP)이고 백업 노드에서 대기(OSU)이지만 데이터베이스가 실행되고 두 노드에서 기본 복제 사이트로 등록됩니다. 이 상황은 일반적으로 장애 조치 중에 이전 기본 노드에서 데이터베이스를 중지하지 못하거나 데이터베이스에 대해 자동 시작이 활성화되어 있거나 데이터베이스 관리자가 클러스터링 소프트웨어 환경 외부의 보조 복제 사이트에서 “hdbnsutil -sr_takeover”를 수동으로 실행하는 경우에 발생합니다. .

스플릿 브레인 문제 피하기

각 유형의 분할 브레인 시나리오를 피하거나 해결하기 위한 권장 사항 SIOS 보호 제품군 클러스터링 환경은 아래와 같습니다.

분할 브레인 시나리오에서 다음과 유사한 메시지가 기록되고 문제가 해결될 때까지 quickCheck 간격(기본값 2분)마다 열려 있는 모든 콘솔에 브로드캐스트됩니다.

EMERG:hana:quickCheck:HANA-SPS_HDB00:136363:WARNING: 서버 hana2-1과 
hana2-2 사이에 일시적인 통신 장애가 발생했습니다. 데이터 손실 위험을 최소화하려면 수동 
개입이 필요합니다. 
이 상황을 해결하려면 hana2-1의 HANA-SPS_HDB00 또는 hana2-2의 HANA-SPS_HDB00과 
같은 리소스 계층 중 하나를 사용하지 마십시오. 
리소스 계층 구조가 서비스에서 제외된 서버는 보조 SAP HANA 시스템 복제 사이트가 됩니다.

해결을 위한 권장 사항:

  1. 각 클러스터 노드의 데이터베이스를 조사하여 어떤 인스턴스에 최신 데이터나 관련 데이터가 포함되어 있는지 확인합니다. 이 결정은 데이터에 대해 잘 알고 있는 자격을 갖춘 데이터베이스 관리자가 수행해야 합니다.
  2. 유지해야 하는 데이터가 포함된 노드의 HANA 리소스는 LifeKeeper에서 활성(ISP)으로 유지되며, 보조 복제 사이트로 다시 등록될 노드의 HANA 리소스 계층 구조는 라이프키퍼. 계층을 서비스에서 제외해야 하는 노드의 HANA 리소스 계층에서 각 리프 리소스를 마우스 오른쪽 버튼으로 클릭하고 서비스 중단 …
  3. SAP HANA 리소스 계층 구조가 성공적으로 중단되면 LifeKeeper는 다음 quickCheck 간격(기본값 2분) 동안 대기 노드를 보조 복제 사이트로 다시 등록합니다. 복제가 재개되면 활성 노드에 없는 대기 노드의 모든 데이터는 손실됩니다. 대기 노드가 보조 복제 사이트로 다시 등록되면 SAP HANA 계층 구조가 고가용성 상태로 돌아갑니다.

SAP HANA 시스템 복제 분할 브레인 해결

이 스플릿 브레인 시나리오에서는 다음과 유사한 메시지가 기록되고 모든 열려 있는 콘솔에 빠르게 브로드캐스트됩니다. 문제가 해결될 때까지 간격(기본값 2분)을 확인합니다.

EMERG:hana:quickCheck:HANA-SPS_HDB00:136364:WARNING: SAP HANA 데이터베이스 
HDB00이 실행 중이며 hana2-1 및 hana2-2 모두에서 기본 마스터로 등록되어 있습니다. 
데이터 손실 위험을 최소화하려면 수동 개입이 필요합니다. 이 상황을 해결하려면 해당 서버에서 
'su – spsadm -c “sapcontrol -nr 00 -function Stop”' 명령을 실행하여 
hana2-2에서 데이터베이스 인스턴스 HDB00을 중지하십시오. 중지되면 보조 SAP HANA 
시스템 복제 사이트가 됩니다.

해결을 위한 권장 사항:

  1. 각 클러스터 노드의 데이터베이스를 조사하여 Active 노드에 없는 중요한 데이터가 Standby 노드에 있는지 확인합니다. 스플릿 브레인 상태에서 대기 노드의 데이터베이스에 중요한 데이터가 커밋된 경우 데이터를 수동으로 활성 노드에 복사해야 합니다. 이 결정은 데이터에 대해 잘 알고 있는 자격을 갖춘 데이터베이스 관리자가 수행해야 합니다.
  2. 누락된 데이터가 대기 노드의 데이터베이스에서 활성 노드로 복사되면 LifeKeeper 경고 메시지에 제공된 명령을 실행하여 대기 노드의 데이터베이스를 중지합니다.

    su – adm -c “sapcontrol -nr <Inst#> -function Stop” 여기서 은 HANA 설치를 위한 소문자 SAP 시스템 ID이고 <Inst#>는 HDB 인스턴스의 인스턴스 번호(예: 인스턴스 번호, 예를 들어 HDB00은 00)

  3. 데이터베이스가 성공적으로 중지되면 LifeKeeper는 다음 quickCheck 간격(기본값 2분) 동안 보조 복제 사이트로 대기 노드를 다시 등록합니다. 복제가 재개되면 활성 노드에 없는 대기 노드의 모든 데이터는 손실됩니다. 대기 노드가 보조 복제 사이트로 다시 등록되면 SAP HANA 계층 구조가 고가용성 상태로 돌아갑니다.

일반적인 스플릿 브레인 시나리오를 인식하고 이를 완화하기 위해 이러한 단계를 수행하면 시간을 절약하고 데이터 무결성을 보호할 수 있습니다.

 

 

의 허가를 받아 재생산 시오스

Filed Under: 서버 클러스터 단순화 Tagged With: 리눅스

고가용성 아키텍처 및 모범 사례

9월 16, 2021 by Jason Aw Leave a Comment

고가용성 아키텍처 및 모범 사례

 

 

고가용성 아키텍처 및 모범 사례

고가용성에 대해 거의 알려지지 않은 사실 13가지

1. 하이퍼바이저 HA는 애플리케이션 HA와 동일하지 않습니다.

주요 오해는 하드웨어 또는 하이퍼바이저에 중복성이 있기 때문에 고가용성을 갖는다는 것입니다. 그러나 하드웨어 및 하이퍼바이저 중복성은 다음을 보장하지 않습니다. 고가용성 응용 프로그램을 위해. 또한 오류 발생 시 응용 프로그램의 오케스트레이션이 올바르게 실행된다는 보장도 없습니다.

2. 고가용성에서 더 큰 것이 더 나은 것은 아닙니다.

당신이 파워리프터라면 더 큰 중량이 더 좋고 더 적은 횟수가 더 좋습니다. 또는 포옹에 대해 이야기하는 경우. (포옹은 우리가 다른 도시에서 온 친구를 만났을 때 하던 일, 한동안 보지 못했던 일을 기억합니다.) 그러나 더 크다는 것이 항상 더 좋은 것을 의미하지는 않습니다. 예를 들어, 더 큰 신장 결석은 확실히 더 좋지 않습니다. 고가용성에서 더 크고 더 복잡한 솔루션을 만든다고 해서 항상 고가용성을 높일 수 있는 것은 아닙니다. 가용성이 같거나 더 적음을 의미할 수 있습니다. 또한 가동 중단 시 처리해야 할 이동 부분이 많은 더 크고 복잡한 시스템이 있음을 의미할 수도 있습니다.

3. 모든 것이 실패… 때때로

응용 프로그래밍 언어는 1950년대로 거슬러 올라갑니다. 그리고 언어, 프로세서, IDE 및 코드 품질이 향상되었지만 현실은 “모든 응용 프로그램은 어느 시점에서 실패”합니다. 예외, 버그, 처리되지 않은 종료, 우발적인 종료, 리소스 고갈 등으로 인한 실패가 발생합니다. 능동/능동 또는 능동/수동 애플리케이션 가용성 전략이 여전히 필요합니다.

4. ‘어떻게’보다 ‘왜’에 집중하라

작업 완료 모드로 뛰어드는 우리의 자연스러운 경향은 필수 자산이지만, 이유에 대한 우리의 질문에 대한 답변에 따라 조정되고 안내되어야 합니다. 비즈니스, 애플리케이션, 데이터베이스 및 이해 관계자 요구 사항을 이해하지 않고 환경에 솔루션을 추가하면 다음 중 하나가 발생합니다.

  • 실패
  • 초과 지출
  • 실적 부진
  • 혼돈과 건축
  • 무엇보다도

가용성 구현에만 집중하는 대신 비즈니스 요구 사항을 이해하고 “이유”에 대한 답을 찾는 데 필요한 리소스와 노력을 투자하십시오.

5. 패치되지 않은 문제는 일반적인 후회의 원인입니다.

하거나 하지 않으면 결과가 있습니다. 패치되지 않은 모든 문제의 결과는 후회입니다. 고객 경험 담당 부사장으로서 저는 고객이 알려진 문제를 적시에 해결하지 못해 발생하는 가동 중지 시간을 직접 목격했습니다.

6. 문서화되지 않은 문제로 인해 다운타임도 발생합니다.

장면을 그려보세요. 새 관리자가 네트워크의 서버를 조사하고 있습니다. 사용 보고서는 서버가 활성 상태가 아니며 연결된 클라이언트가 없음을 나타냅니다. 서버를 인식하지 못하고 “태그”, 문서 또는 기타 식별자를 찾지 못한 새 관리자는 서버를 종료해야 한다고 생각합니다. 불행히도 문서화되지 않고 통신되지 않은 인스턴스는 실제로 대기 서버로, 기본 서버가 예기치 않게 충돌할 때 제거로 인해 가동 중지 시간이 발생합니다. 이것은 허구의 이야기가 아닙니다. 이것은 서버를 유휴 QA 시스템으로 잘못 식별하고 패치 작업 전에 종료한 새 관리자의 실화입니다.

7. 안일함도 적이다

온프레미스나 클라우드 또는 그 사이의 어느 곳에서든 가용성이 “설정하고 잊어버릴 수 있는” 것이라면 모두가 좋아할 것입니다. 그러나 인생에서 “설정하고 잊어버리십시오”만큼 간단한 것은 거의 없습니다. 미래 가용성의 가장 큰 적 중 하나는 지금 고가용성을 통한 성공입니다. 재해가 거의 없고 팀이 지속적인 안정성을 실현했다고 확신할 때 안주가 개입할 수 있습니다. 성공은 우리로 하여금 아무 것도 변하지 않을 것이라고 생각하게 만들고 고가용성에 대한 안일함은 고가용성의 적입니다. 기업 주변과 기업 내부의 상황이 변화하고 있습니다. 클라우드가 변하고 비즈니스 요구가 변하고 애플리케이션과 운영 체제도 변하고 있습니다.

8. 변화는 어렵다

변화는 어렵다. 취침 전에 케이크의 두 번째 조각을 포기하려고 애쓰는 단 것을 좋아하는 사람에게 물어보십시오. 고가용성에서도 유사한 저항이 발생합니다. 팀은 재난을 경험한 팀이라도 좋은 변화라도 변화를 꺼리는 경우가 많습니다. 그들에게는 비전, 이유에 대한 이해, 지원이 필요합니다. 솔루션을 갖춘 다른 팀은 불안정을 초래하거나 새로운 위험에 노출될까 두려워 고가용성을 개선하기를 꺼립니다.

9. 모든 변화가 좋은 변화는 아니다

변화가 좋을 때 변화가 좋다. 고가용성 솔루션 및 아키텍처에 대한 변경을 고려할 때 목표, 요구 사항 및 가용성 증가 범위 내에서 변경 사항을 분석하는 것이 중요합니다. 안정성을 높이고, 중요한 구성 요소에 대한 보호를 추가하고, 대안을 제거하고, 서비스 가용성을 최적화하고, 철저하게 테스트하는 변경은 좋은 변경입니다.

10. 더 싼 것이 항상 좋은 것은 아니다

저렴하다고 항상 좋은 것은 아닙니다. 저렴한 솔루션은 일반적으로 가격표가 더 낮지만 이상적이지 않은 여러 제한 사항이 있을 수도 있습니다. 더 낮은 가격표가 있는 경우 애플리케이션 인식 부족, 제한된 오케스트레이션, 숨겨진 복잡성, 수동 복구 및 장애 조치 , 사용자 검증이 없는 것으로 제한됩니다. 저렴한 솔루션에는 고객 지원이 포함되지 않을 수도 있습니다. 더 저렴한 솔루션에 지원이 포함되는지 또는 지원이 추가 및 상당한 애드온 비용인지 이해해야 합니다.

컴퓨팅, 디스크 또는 스토리지가 감소된 저렴한 배포에도 동일하게 적용됩니다. 가격표와 월별 비용이 더 낮을 수 있지만 솔루션이 이상적인 용량보다 적게 작동할 수도 있습니다.

11. 시끄러운 것은 효과적이지 않다

늑대 우는 소년의 이야기를 들어본 적이 있습니다. 경고 폭풍을 생성하는 애플리케이션 모니터링 솔루션은 나중에 무시되는 솔루션입니다. 경고를 제공하는 솔루션을 갖는 것은 좋지만 해당 솔루션이 오류 또는 초과로 중요한 경고를 트리거하면 효과가 없습니다.

12. 고가용성은 단순한 제품이나 하드웨어 솔루션이 아닌 문화이자 사고방식입니다.

소프트웨어, 하드웨어, 프로세스, 솔루션 및 서비스는 모두 고가용성의 일부입니다. 그러나 IT 기능 및 사업부 전반에 걸친 동의 없이는 가치, 비즈니스 안정성, 고객 만족도 향상 및 위험 감소에 대한 논의 대신 좌절감과 계속해서 예산 논의의 원천이 될 것입니다.

13. 아직 늦지 않았다

희망은 고가용성을 위한 전략이 아니며 치명적인 재해나 애플리케이션 오류가 발생하지 않기를 바라는 것도 전략일 필요가 없습니다. 고가용성 엔터프라이즈 아키텍처를 설계하고 설계하는 것은 마지막 재해 이후 몇 주 또는 몇 달이 지난 경우에도 가능합니다.

SIOS에 문의 에 대해 자세히 알아보기 고가용성 솔루션 당신의 신청을 위해.

– Cassius Rhue, VP, 고객 경험 재현 시오스

 

 

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

클라우드 마이그레이션을 복잡하게 만드는 12가지 질문

9월 10, 2021 by Jason Aw Leave a Comment

클라우드 마이그레이션을 복잡하게 만드는 12가지 질문

클라우드 마이그레이션을 복잡하게 만드는 12가지 질문

클라우드 마이그레이션 권장사항

“클라우드가 점점 더 복잡해지고 있습니다.”는 클라우드 컴퓨팅 및 클라우드 마이그레이션의 붐으로 인한 변화와 기회에 대해 자세히 설명하는 1시간 길이의 웨비나의 첫 번째 진술이었습니다.발표자는 기존 IT가 현재 직면하고 있는 클라우드 관련 사항에 대한 개요를 계속했습니다. AWS , 하늘빛 , GCP 또는 다른 공급자.

클라우드로의 전통적인 전환 과정에서 복잡하게 드러난 9가지 영역이 있습니다.

  • 정의
  • 가격
  • 네트워킹
  • 보안
  • 사용자, 역할 및 프로필
  • 애플리케이션 및 라이선스
  • 서비스 및 지원
  • 유효성
  • 백업

SIOS Technology Corp의 고객 경험 부사장으로서 저는 다음 영역이 클라우드로의 전환에 어떤 영향을 미칠 수 있는지 확인했습니다. 이러한 복잡성을 완화하기 위해 소비자는 관리형 서비스 제공업체, 클라우드 솔루션 설계자, 계약자 및 컨설턴트, 수많은 관련 서비스, 가이드, 블로그 게시물 및 관련 기사를 찾고 있습니다. 외부 또는 아웃소싱 리소스로 전환하는 과정에서 클라우드의 복잡성이 완전히 제거되지 않는 경우가 많습니다.대신, 지원하거나 클라우드로 전환하기 위해 고용한 회사와 팀은 여전히 장애물, 과속 방지턱, 딸꾹질 및 차질에 직면합니다.

대부분의 경우 클라우드로 마이그레이션할 때 이러한 복잡성과 속도 저하가 12가지 답이 없는 질문에서 비롯됩니다.

  1. 클라우드로 전환하는 우리의 목표는 무엇입니까?
  2. 현재 온프레미스 아키텍처는 무엇입니까?문서, 목록, 순서도 또는 요리책이 있습니까?
  3. 대상 클라우드 공급자 플랫폼에서 모든 애플리케이션, 데이터베이스, 가용성 및 관련 공급업체가 지원됩니까?
  4. 현재 온프레미스 위험 및 제한 사항은 무엇입니까?보호되지 않는 애플리케이션은 무엇이며, 온프레미스에서 직면하는 가장 일반적인 문제는 무엇입니까?
  5. 클라우드 아키텍처 및 설계를 담당하는 사람은 누구입니까?이 아키텍처와 디자인은 현재 정의와 클라우드 제공자의 정의를 어떻게 설명합니까?
  6. 주요 이해 관계자는 누구이며 비즈니스 프로젝트의 이정표, 비즈니스 동인 및 기한은 무엇입니까?
  7. 프로젝트 계획 및 이정표를 공급업체와 공유했습니까?
  8. 현재 프로세스, 거버넌스 및 비즈니스 요구 사항은 무엇입니까?
  9. 마이그레이션 예산은 얼마이며 여기에는 인력 보강, 교육 및 서비스가 포함됩니까? 지속적인 유지 관리, 라이선스 및 운영 비용에 대해 어떻게 예상하십니까?
  10. 팀의 기존 기술과 책임은 무엇입니까?
  11. 누가 거버넌스, 프로세스, 새로운 클라우드 모델, 다양한 기존 역할과 책임을 업데이트할 책임이 있습니까?
  12. IaaS에서 SaaS 모델로 이동할 애플리케이션, 서비스 또는 기능은 무엇입니까?

클라우드에 대한 목표 파악

따라서 이 12가지 질문에 답하면 클라우드 마이그레이션을 개선할 수 있습니다. 질문에서 알 수 있듯이 클라우드에 대한 목표를 이해하는 것이 첫 번째이자 가장 중요한 단계입니다.”AWS, Azure 또는 Google과 같은 클라우드 서비스 공급자가 특정 애플리케이션에 필요한 서버, 스토리지 및 통신 리소스를 제공할 수 있다”는 것은 거의 보편적으로 받아들여지고 있지만, 많은 고객에게 이것은 “컴퓨터가 필요하지 않습니다. 하드웨어 및 해당 하드웨어를 관리하는 인력.” 이러한 사실 때문에 고객은 여전히 고려해야 할 추가 클라우드 기회와 격차를 고려하지 않고 장비 또는 데이터 센터 통합 또는 축소에 집중하는 경우가 많습니다. 예를 들어, 클라우드 하다 하드웨어 관리를 제거하지만 “ 하지 않습니다 모니터링 및 복구를 위해 애플리케이션과 해당 종속성이 필요로 하는 모든 요구 사항을 제거하십시오. IaaS 모델.목표를 아는 것은 클라우드 여정을 계획하는 데 큰 도움이 됩니다.

현재 온프레미스 아키텍처 파악

클라우드(또는 모든 새로운 플랫폼)로의 적절한 마이그레이션에 필요한 두 번째 중요한 질문 범주는 현재 온프레미스 아키텍처를 이해하는 것입니다. 이 단계는 가용성이 필요한 중요한 애플리케이션을 식별하는 데 도움이 될 뿐만 아니라 기본 종속성과 클라우드의 스토리지, 네트워킹 및 컴퓨팅 변경 사항을 기반으로 해당 애플리케이션, 데이터베이스 및 백업 솔루션에 필요한 모든 변경 사항을 식별하는 데 도움이 됩니다.이 질문에 답하는 것은 클라우드에 대한 애플리케이션 및 솔루션의 준비 상태를 평가하고 현재 위험을 수량화하는 핵심 단계이기도 합니다.

이러한 질문을 통해 큰 이점을 얻을 세 번째 영역은 현재 제한 사항을 논의하고 수량화할 때 발생합니다.종종 우리는 이 발견 단계에서 클라우드에 존재하지 않는 현재 솔루션의 한계에 대한 문을 여는 것을 봅니다.예를 들어, 최근 우리 서비스 팀은 SQL 데이터베이스 클러스터의 성능 문제로 영향을 받는 고객과 협력했습니다.마이그레이션을 지원하는 SIOS 전문가는 솔루션과 아키텍처, VM 크기 결정에 대해 문의했습니다. 잠시 후 더 큰 애플리케이션 크기의 인스턴스가 배포되어 고객이 컴퓨팅, 메모리 및 스토리지에 대한 온프레미스 제한으로 인해 수용한 제한 사항을 수정했습니다.마찬가지로 우리는 스토리지에 민감한 고객과 협력했습니다.그들은 디스크 용량 제약으로 인해 더 작은 디스크와 빈번한 크기 조정 정책으로 응용 프로그램을 실행했습니다. 스토리지 비용을 고려해야 하지만 최소한의 마진으로 운영하는 것은 과거의 한계가 될 수 있습니다.

비즈니스 및 거버넌스 변경 이해

마지막 질문 그룹은 팀에서 더 이상 클라우드에 적용되지 않을 수 있으므로 업데이트하거나 교체해야 하는 일정, 비즈니스 영향, 마감일 및 거버넌스 변경 사항을 이해하는 데 도움이 됩니다. 클라우드로의 마이그레이션은 순조로운 전환과 여정이 될 수 있습니다.그러나 여행 중 어디에 있는지, 언제 여행을 완료해야 하는지 평가하지 못하면 악몽에 빠질 수 있습니다. 타이밍을 이해하는 것은 중요하며 이해 관계자, 애플리케이션 공급업체, 비즈니스 이정표 및 비즈니스 시즌을 고려하여 크게 도움을 받을 수 있습니다.이기적으로 SIOS Technology Corp.은 서비스 제공자로서 놀라움을 최소화하기 때문에 고객이 이정표를 이해하기를 바랍니다. 그러나 우리는 또한 고객이 부서와 이해 관계자 간의 불일치를 자주 발견하므로 이러한 질문에 답할 것을 권장합니다. DBA는 컷오버가 해당 월의 마지막 주말에 발생할 것으로 생각하지만 재무부는 같은 달의 마지막 주말에 장부를 마감할 계획입니다. 또는 IT 팀은 전환이 월요일에 발생할 수 있다고 생각하지만 애플리케이션 팀은 수요일까지 사용할 수 없으며 아마도 가장 중요한 것은 법무팀이 전환을 가져오는 데 필요한 새로운 NDA, 계약, 라이선스 및 거버넌스 변경 목록을 검토하지 않았다는 것입니다. 모두 함께.

고객이 안전하고 공감하는 마음으로 질문을 처리할 때 종종 등장하는 것은 조각, 소유권, 프로세스 및 의사 결정권자의 퍼즐입니다. 이 퍼즐은 클라우드 제공업체 상자 상단과 예산, 인력 배치, 교육에 대한 정직한 대화를 사용하여 다시 결합해야 합니다. , 및 서비스.최종 결과는 완벽한 마이그레이션이 아닐 수 있지만 확실히 성공적인 마이그레이션이 될 것입니다.

클라우드 마이그레이션 전략 및 고가용성 구현에 대한 도움이 필요하면 SIOS Technology Corp.에 문의하십시오. – Cassius Rhue, VP, Customer Experience common에 대해 자세히 알아보기 클라우드 마이그레이션 과제 .

에 대한 몇 가지 오해에 대해 읽어보십시오. 클라우드의 가용성.

에서 재생산 시오스

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

  • 1
  • 2
  • Next Page »

최근 게시물

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

가장 인기있는 게시물

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

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