여기서 완전히 명확하게 설명할 수 없다면 용서해 주십시오. 의도한 것은 아닙니다. 저는 현재 관리자처럼 행동해야 하는 아주 작은 회사의 고위 개발자입니다.
어쨌든, "클러스터"에 SQL Server 2008 Standard를 탑재한 오래된 Dell 서버 2대가 있다는 이야기입니다. 나는 그것이 무엇을 의미하는지 아직 100% 명확하지 않기 때문에 따옴표로 묶었습니다. 우리는 2개의 새로운 블레이드 서버를 보유하고 있으며 기존 데이터베이스를 새로운 하드웨어로 이동하려고 합니다.
좋아, 여기에 문제가 있습니다. 가동 중지 시간이 거의 또는 전혀 없이 이 작업을 수행해야 합니다. 패시브 노드를 제거한 다음 새 서버 중 하나를 가져올 수 있다는 말을 들었습니다. 하지만 이는 위험한 단계라는 말도 들었습니다. 문제가 발생하여 클러스터가 실패하고 활성 서버가 다시 돌아올 수 없기 때문에 아무 것도 남지 않을 수 있기 때문입니다.
누구든지 이 문제를 처리하는 방법에 대해 생각하고 있습니까? 성공을 보장하는 유일한 방법은 새 하드웨어에 새 클러스터를 가져온 다음 데이터베이스를 하나씩 마이그레이션하는 최소한 하루의 가동 중지 시간을 갖는 것이라고 들었습니다.
[편집] 여전히 이 질문과 관련되어 있으므로 다른 질문을 추가하고 싶습니다. 클러스터에서 머신을 제거하는 것이 가능합니까? 그런 다음 제거된 노드를 활성 시스템으로 사용하여 새 클러스터를 만든 다음 여기에 새 서버를 가져오시겠습니까? 문제가 발생할 경우 새 시스템을 교체하고 교체하는 동안 기존 클러스터를 효과적으로 보존하시겠습니까?
답변1
가동 중지 시간이 거의 또는 전혀 없음
고가용성이 필요하다는 점에서 기업을 운영해야 한다는 것이 지금 별 도움이 되지 않지만, 이 상황에서 사용할 가장 확실한 기능은 클러스터에 최대 16개의 노드를 보유할 수 있는 기능이므로 귀하의 경우에는 추가했을 것입니다. 2개의 노드가 더 이상 필요하지 않은 노드를 제거했습니다. 하드웨어를 업그레이드하는 동안 버전 업그레이드를 고려하겠습니다.
... 하지만 이는 위험한 단계라는 말도 들었습니다. 문제가 발생하여 클러스터가 실패하고 활성 서버가 다시 작동할 수 없기 때문에 아무 것도 남지 않을 수 있기 때문입니다.
무엇이든 가능합니다. 서버 208 sql 2008 장애 조치 클러스터가 단순히 중단되는 것을 본 적이 없지만 이론적으로는 가능합니다. 활성 노드는 노드 업그레이드 중에 "중지"되지 않으므로 중단할 사항이 없습니다. 클러스터는 장애 조치 가능성 없이 단순히 노드 1개에서 실행됩니다. 합리적인 최악의 시나리오는 이전 노드가 어떤 이유로 작동하지 않고 교체 노드가 추가되지 않는 것입니다. 이 경우 서버를 추가하지 못하게 하는 문제가 해결될 때까지 장애 조치 기능 없이 실행됩니다.
성공을 보장하는 유일한 방법은 새 하드웨어에 새 클러스터를 가져온 다음 데이터베이스를 하나씩 마이그레이션하는 최소한 하루의 가동 중지 시간을 갖는 것이라고 들었습니다.
그것이 아마도 그 일을 하는 사람의 성공을 보장하는 유일한 방법일 것입니다. "클러스터를 이동하는 데 하루 동안 가동 중지 시간이 걸린다면 애초에 왜 클러스터를 구축해야 할까요? 머신 2대를 구입하고 1개는 남겨두고 그런 종류의 가용성을 위해 준비할 수 있습니다."라는 순진한 질문을 던지고 싶습니다. 간단히 말해서 실제로 이전에 클러스터 작업을 수행하고 관련 기술을 이해하는 사람을 찾아야 합니다. 고유한 문제가 없다고 가정합니다(예: 귀사에서 일부거의클러스터에서 실행되는 클러스터 인식 소프트웨어) 대부분의 전문 Microsoft 관리자는 기존 작동 클러스터에 하드웨어를 교체/추가하는 데 하루의 가동 중지 시간이 걸릴 것이라고 말하면 당황스러울 것이라고 생각합니다.
답변2
우선, 귀하의 질문 끝에 있는 권장 전략은 제가 권장하는 방식이기도 하지만, 이것이 옵션이 아니기 때문에 제가 처리하는 방법은 다음과 같습니다. 클러스터에 대해 혼란스러워 보입니다. 기본적으로 두 서버 모두 SQL이 설치되어 있고 클러스터 서비스가 있으며 클러스터 서비스를 통한 명령을 사용하면 한 서버에서 다른 서버로 SQL을 "롤"할 수 있습니다. 제가 당신 입장이라면 당신이 제안한 대로 모든 서비스를 하나의 노드로 롤업하고, 클러스터에서 두 번째 노드를 제거하고, 새 서버 중 하나를 클러스터 노드로 추가하고, 모든 서비스를 새 클러스터 노드로 롤백할 것입니다. 두 번째 새 노드를 추가하고 클러스터에서 두 번째 이전 노드를 제거합니다.
**클러스터 서비스 및/또는 클러스터된 SQL 설치에 익숙하지 않고 라이브 시스템에서 이 작업을 시도하는 경우 이는 매우 좋지 않은 결과를 초래할 수 있습니다. 하루의 계획된 가동 중지 시간보다 훨씬 더 나쁩니다. 클러스터 경험이 있는 컨설턴트를 고용하거나, 이것이 옵션 설정이 아닌 경우 테스트 환경을 설정하여 프로세스 내부와 외부를 테스트할 수 있습니다.
여기클러스터에 노드를 추가하는 단계에 대한 링크입니다.
답변3
하드웨어를 다시 사용하려는 경우가 아니면 이전 클러스터를 전혀 중단할 필요가 없습니다. 나는 다음을 추천합니다:
- 새 블레이드로 새 클러스터 만들기
- 새 클러스터에서 SQL을 제거하고 드라이브 문자, 경로, 포트 및 인스턴스 이름(해당하는 경우)을 동일하게 유지하세요.
- 설치 후 마스터 및 msdb 데이터베이스를 이전 SQL 서버에서 새 데이터베이스로 복원/교체하여 로그인 및 작업을 가져오거나 이전 SQL 서버에서 작업을 스크립트로 작성하고 sp_help_revlogins를 사용하십시오.
- 데이터를 최신 상태로 유지하기 위해 이전 서버에서 새 서버로 데이터베이스를 로그 전달하거나 미러링합니다.
이렇게 하면 OS 및 SQL을 새로 설치하면서 새 인스턴스가 이전 인스턴스와 동일한 상태가 됩니다. 새 클러스터로 전환하려면 이전 인스턴스의 이름이 INSTA이고 새 인스턴스의 이름이 INSTB라고 가정하고 다음을 수행할 수 있습니다.
- 이전 SQL 인스턴스를 오프라인으로 전환
- 새 서버에서 데이터베이스 복구
- Active Directory의 DNS에서 INSTA DNS 레코드 삭제
- INSTB를 가리키는 Active Directory DNS에 새 CNAME(별칭) DNS 레코드를 만듭니다.
이 작업이 완료되면 애플리케이션은 SQL 인스턴스의 이전 이름을 연결해야 하지만 그렇게 하면 애플리케이션이 새 서버로 연결됩니다. DNS 변경 작업을 더 빠르게 수행하려면 모든 응용 프로그램 서버에서 "ipconfig /flushdns"를 실행해야 할 수도 있습니다. 이전 이름을 ping하여 다시 가리키는지 확인하십시오. 롤백해야 할 경우를 대비해 이전 클러스터를 유지할 수 있기 때문에 컷오버에 이 방법을 사용합니다. SQL Server 네트워크 이름 매개변수를 다른 것으로 변경할 때까지는 이전 SQL 인스턴스를 가져올 수 없지만, 일단 작업이 완료되면 롤백하려는 경우 DNS 별칭을 이전 인스턴스로 다시 지정하면 됩니다.
답변4
이것이 작동하는지 알기 위해 하드웨어의 세부 사항을 알지 못한 채 기존 패시브 노드를 새 서버에 이미지화하는 것이 좋습니다. 이미지를 새 하드웨어에 배치할 수 있는 Acronis와 같은 제품을 사용하면 기본적으로 패시브 노드를 새 하드웨어로 이동할 수 있습니다. 그런 다음 전원을 켜고 (가능한 한) 제대로 작동하는지 확인한 다음 새 하드웨어로 장애 조치를 시도할 수 있습니다. 잘못될 수 있는 일이 많이 있지만 Jim B가 말했듯이 새 하드웨어로 제대로 장애 조치되거나 작동하지 않고 이전 하드웨어로 돌아가야 할 가능성이 높습니다. 작동하면 다른 노드에서 프로세스를 반복할 수 있습니다. 그렇지 않은 경우 기존 패시브 노드의 전원을 다시 켜고(파괴할 필요가 없음) 다른 것을 시도해 볼 수 있습니다.