SharePoint 2010 배포: SharePoint 2010으로의 업그레이드 준비
SharePoint 2010으로 바로 업그레이드할 수 있다면 좋겠지만 그 전에 충분한 계획이 뒷받침되어야 합니다. 이 문서에서는 업그레이드를 계획하는 절차를 안내합니다.
Brien Posey
SharePoint 2010으로의 업그레이드는 지금까지의 업그레이드와는 다릅니다. 따라서 업그레이드 계획 절차를 시작하기 전에 SharePoint 2010의 시스템 요구 사항을 익혀야 합니다. SharePoint 2010은 이전 버전의 SharePoint와 달리 64비트 전용입니다. 따라서 64비트 버전의 Windows Server 2008 또는 Windows Server 2008 R2에 설치해야 합니다.
SharePoint를 설치하려면 SQL Server 데이터베이스가 필요한데, 꼭 SharePoint와 동일한 서버에 있지 않아도 됩니다. SharePoint 2010도 SQL Server가 있어야 하지만 몇 가지 주요 부분이 달라졌습니다. SharePoint 2010을 설치하려면 64비트 버전의 SQL Server 2005 또는 2008에서 실행될 데이터베이스가 필요합니다. SharePoint 서버에 로컬로 데이터베이스가 설치되든 아니든 관계없이 동일한 요구 사항입니다.
엄연히 말하면 시스템 요구 사항은 아니지만 사용 중인 웹 브라우저도 고려해야 합니다. SharePoint2010은 웹 표준을 더 잘 활용하도록 만들어졌습니다. 따라서 사용자가 Internet Explorer를 사용하든지 Firefox(3.x 이상)를 사용하든지 관계없이 일관된 환경을 사용할 수 있습니다. 하지만 여기서 한 가지 주의할 점은 SharePoint 2010이 Internet Explorer 6에 대한 지원을 제한했다는 점입니다. IE6 사용자도 SharePoint 콘텐츠를 보는 데는 아무 문제가 없지만 콘텐츠를 제작하려면 IE7 이상(또는 Firefox 3.x 이상)이 필요합니다.
사용 중 업그레이드
이미 알고 계실지 모르겠지만 SharePoint 2010은 Microsoft Office SharePoint Server(MOSS) 2007에서의 사용 중 업그레이드를 허용합니다. 그러나 SharePoint 2010은 64비트이므로 기존의 MOSS 2007이 64비트 버전의 Windows Server 2008에서 실행 중인 경우에만 사용 중 업그레이드를 할 수 있습니다. 기존의 SharePoint 서버가 필요한 시스템 요구 사항을 충족하는 경우 SharePoint 팜의 각 서버에서 사용 중 업그레이드를 수행할 수 있습니다.
SharePoint는 이러한 업그레이드를 완벽하게 지원하지만 SharePoint가 단순하게 배포되어 있고 사용자 지정 설정이 전혀 없는 경우에만 사용 중 업그레이드를 수행하는 것이 좋습니다. 좀 더 복잡한 환경에서는 업그레이드 절차에 대한 높은 수준의 제어가 필요하므로 전체 마이그레이션이 권장됩니다. 기존에 사용자 지정한 설정이 있고, 이러한 설정을 실수로 덮어쓰지 않으려는 경우에도 전체 마이그레이션이 권장됩니다.
마이그레이션하려면 일반적으로 SharePoint 2010을 실행하는 완전히 새로운 SharePoint 팜을 만들어야 합니다. 이렇게 한 뒤에 기존의 SharePoint 데이터베이스를 새 팜에 연결할 수 있습니다. 또한 사용 중 업그레이드와 새로운 SharePoint 2010 서버를 결합하는 혼합 마이그레이션 전략을 사용할 수도 있습니다.
업그레이드 전 검사
사용 중 업그레이드를 수행하든 마이그레이션을 수행하든 관계없이, 실제로 업그레이드 절차를 시작하기 전에 몇 가지 계획 및 준비 과정이 수반되어야 하는 점은 똑같습니다. SharePoint 2010으로의 업그레이드를 준비하는 과정에서 업그레이드 전 검사기 사용은 매우 중요한 단계 중 하나입니다. Microsoft에서는 MOSS 2007 출시 전에 SharePoint 배포를 MOSS 2007로 업그레이드하기 전에 정상적인 상태인지 확인하는 데 도움이 되는 Prescan.exe 유틸리티를 발표했습니다.
그 당시에는 Prescan.exe가 매우 유용한 도구였지만 SharePoint 2010의 배포 전 분석에는 그다지 적합하지 않습니다. 이에 따라 Microsoft는 업그레이드 전 검사기라는 새로운 도구를 발표했습니다. 업그레이드 전 검사기는 Prescan.exe와 비교할 때 엄청난 발전입니다. 먼저 업그레이드 전 검사기는 읽기 전용이므로 SharePoint 서버가 변경되지 않을지 걱정할 필요가 없습니다.
업그레이드 전 검사기의 가장 뛰어난 점은 이전의 Prescan.exe보다 훨씬 더 철저하게 문제를 탐지한다는 점입니다. 또한 확장도 가능합니다. 업그레이드 전 검사기에는 SharePoint 서버를 분석할 때 사용하는 규칙 집합이 포함되어 있습니다. 이러한 규칙은 XML 형식이므로 필요할 경우 사용자 지정 규칙을 만들 수 있습니다. XML 기반 규칙을 사용하면 Microsoft에서 권장하는 최상의 방법이 변경될 경우 업그레이드 전 검사기를 쉽게 업데이트할 수 있다는 장점도 있습니다.
업그레이드 전 검사기의 가장 좋은 점은 이 검사기가 수집하는 정보에 있습니다. Microsoft는 SharePoint 2010으로의 업그레이드를 준비하기 위한 도구로서 업그레이드 전 검사기를 설계했지만 일부 조직에서는 이 도구를 다른 목적으로 사용하고 있습니다. 어떤 회사에서는 재해 복구 계획 과정에서 업그레이드 전 검사기를 사용합니다. 오류가 발생한 SharePoint 서버를 복구하기 위해 이 유틸리티가 실제로 어떠한 작업을 수행하는 것은 아니지만 이 유틸리티에서 수집한 정보는 SharePoint 배포를 다시 빌드해야 하는 경우에 큰 도움이 될 수 있습니다. 물론 오류가 발생하기 전에 도구를 실행하는 것이 더 좋습니다.
이와 유사하게 다른 조직에서는 SharePoint 서버가 일관된 방식으로 구성되어 있는지 확인하기 위한 도구로 업그레이드 전 검사기를 사용합니다. 각 SharePoint 서버에서 업그레이드 전 검사기를 실행하면 각 서버의 보고서를 비교하고 개별 구성 요소 중에 회사 정책을 준수하지 않는 것이 있는지 확인할 수 있습니다.
그렇다면 업그레이드 전 검사기는 어디에서 얻을 수 있을까요? 아마 여러분이 이미 가지고 있을지도 모릅니다. Microsoft는 MOSS 2007 SP2에 업그레이드 전 검사기를 추가했습니다. 그러나 여러분의 기대와는 달리 업그레이드 전 검사기는 독립 실행형 도구가 아니라 STSADM.EXE 유틸리티에 내장되어 있는 도구입니다. 그런데 필자는 SP2를 설치한 후 테스트 서버를 몇 번 다시 부팅한 뒤에야 새 STSADM.EXE 기능에 액세스할 수 있었습니다.
이제 업그레이드 전 검사기의 작동 원리에 대해 알아보겠습니다. 앞서 말했다시피 업그레이드 전 검사기는 XML 기반 규칙 파일을 구문 분석한 후 이러한 규칙을 바탕으로 SharePoint 배포를 분석하는 방식으로 작동합니다. 업그레이드 전 검사기에는 기본 제공되는 규칙 집합이 포함되어 있습니다. Best Practice Analyzer에 기반을 둔 이러한 규칙은 OssPreUpgradeCheck.xml이라는 파일 내에 존재합니다. 그림 1을 보면 이 파일을 쉽게 이해할 수 있습니다.
그림 1 업그레이드 전 검사기는 XML 기반 규칙 파일을 사용합니다.
업그레이드 전 검사를 실행할 때는 이 규칙 파일을 명시적으로 호출할 필요가 없습니다. 업그레이드 전 검사에서 기본적으로 이 파일을 호출하기 때문입니다. 사용자 지정 규칙 파일을 사용할 수도 있습니다. 업그레이드 전 검사기 실행을 위한 전체 구문은 다음과 같습니다.
STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “<rule file name>”] [-ListRuleFiles]] [-LocalOnly]
위의 구문에서 볼 수 있듯이 유일한 필수 매개 변수는 –O와 PreUpgradeCheck라는 단어입니다. –RuleFiles 매개 변수는 선택 사항이며 사용할 규칙 파일을 수동으로 지정하려는 경우에만 사용합니다. 마찬가지로 –ListRuleFiles 매개 변수를 사용하면 사용 가능한 규칙 파일을 표시할 수 있습니다. 마지막으로 –LocalOnly 매개 변수는 로컬 SharePoint 서버에 대해서만 규칙을 실행하는 데 사용할 수 있습니다.
업그레이드 전 검사기의 작동 원리에 대한 이해를 돕기 위해 그림 2를 보십시오. 그림에서 볼 수 있듯이 필자는 먼저 명령 프롬프트 창을 열고 디렉터리 구조에서 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN으로 이동한 다음 여기에서 다음 명령을 실행했습니다.
STSADMIN.EXE –O PreUpgradeCheck]
.jpg)
그림 2 업그레이드 전 검사기가 사용자의 SharePoint 배포를 테스트합니다.
그림 2에서 볼 수 있듯이 업그레이드 전 검사기는 SharePoint 배포에 대한 여러 가지 테스트를 수행합니다. 각 테스트의 결과는 색상으로 구분됩니다. 빨간색은 실패한 테스트를 나타내고, 녹색은 서버가 테스트에 통과했음을 나타냅니다. 정보 항목은 노란색으로 표시됩니다.
당연히 업그레이드 전 검사기의 출력 내용은 그리 자세하지는 않습니다. 그림 2의 나와 있는 화면 캡처를 보면 테스트가 통과 또는 실패했는지만 표시되고 자세한 정보는 볼 수 없습니다. 그러나 화면의 아래쪽을 보면 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs 폴더에 있는 HTML 파일을 통해 결과를 검토할 수 있다는 메시지가 있는 것을 알 수 있습니다.
업그레이드 전 검사기를 실행할 때마다 3가지 로그 파일이 생성됩니다. 이러한 로그 중 하나가 바로 업그레이드 검사 출력 끝 부분에 언급된 HTML 파일이며 LOG 파일과 XML 파일도 있습니다. 이러한 로그 파일을 사용할 수도 있지만 HTML 파일이 가장 읽기 편합니다.
앞서 말했듯이 업그레이드 전 검사기는 다량의 정보를 수집합니다. 따라서 전체 정보를 표시하기 위해 결과 로그도 매우 길어질 수밖에 없습니다. 그림 3을 보면 HTML 로그가 어떻게 생겼는지 알 수 있습니다.
.jpg)
그림 3 업그레이드 전 검사 결과는 웹 브라우저를 사용하여 볼 수 있습니다.
사용자 지정 설정 확인
업그레이드 계획 절차에서 또 다른 중요한 단계는 SharePoint 서버에서 적용한 사용자 지정 설정을 확인하는 과정입니다. 사용 중 업그레이드를 수행하든 마이그레이션을 수행하든 관계없이 사용자 지정 설정은 실수로 다른 설정에 의해 쉽게 덮어 쓰일 수 있습니다. 따라서 업그레이드 후 필요한 경우에 쉽게 다시 적용할 수 있도록 사용자 지정 설정을 문서화하고 이러한 파일의 백업을 만들어야 합니다.
SharePoint 환경을 활용하면서 여러분이 모든 사용자 지정 설정을 문서화해 놓으셨기를 바랍니다. 현실적으로 모든 변경 내용을 추적하기란 어려운 일입니다. 따라서 모든 사용자 지정 설정이 잘 문서화되었다고 생각하더라도 사용자 지정 로그를 검토해 보시기를 바랍니다. 아쉽게도 SharePoint에는 사용자 지정 설정을 확인하는 기본 제공 도구가 포함되어 있지 않습니다. 그렇다고 해서 SharePoint 서버에서 모든 파일을 일일이 검토해야 한다는 말은 아닙니다.
사용자 지정 설정을 확인하는 한 가지 방법은 차이점 비교 기술을 사용하는 것입니다. 이 기술의 개념은 기본 MOSS 2007 서버(프로덕션 서버와 동일한 패치를 실행 중이어야 함)를 설정한 다음 차이점 비교 프로그램을 사용하여 프로덕션 서버의 파일 중 완전히 깨끗한 SharePoint 서버와 다른 파일이 있는지 확인하는 것입니다.
Microsoft에서는 WinDiff의 사용을 권장하지만 이외에도 많은 차이점 비교 유틸리티를 사용할 수 있으며 이 중에는 WinDiff보다 더 광범위한 기능이 있는 유틸리티가 많이 있습니다.
업그레이드 프로세스 테스트
SharePoint 2010으로의 전환을 준비하면서 업그레이드 방법에 대한 계획을 세우는 시기가 반드시 오게 됩니다. 업그레이드 전 검사기를 통해 보고된 모든 문제를 해결했다고 가정하면 업그레이드 절차가 상대적으로 원활하게 진행됩니다. 문제 발생의 여지를 남겨두어서는 안 됩니다.
프로덕션 서버를 업그레이드하기 전에, MOSS 2007을 격리된 테스트 환경에 배포하고 테스트 환경에서 업그레이드 계획을 테스트해 보십시오. 테스트 환경을 사용하면 업그레이드 절차에 익숙해질 뿐만 아니라 실제로 업그레이드하게 되었을 때 발생할 수 있는 문제를 확인할 수 있습니다.
중소기업(SMB)의 경우 가상 서버를 몇 대 설정한 다음 프로덕션 서버의 백업을 테스트 서버에 복원하는 방법이 가장 좋습니다. 이렇게 하면 프로덕션 환경과 거의 동일한 환경에서 업그레이드 계획을 테스트할 수 있습니다.
대규모 조직에서는 프로덕션 SharePoint 배포와 똑같은 복제본을 만드는 것이 현실적으로 어려울 것입니다. 이러한 경우에는 프로덕션 배포와 유사한 방식으로 구성된 소규모 환경을 설정하는 것이 좋습니다. 또한 SharePoint 서버에서 일부 백업본만 테스트 환경에 복원해 보는 것도 좋습니다. 이 방법은 다소 부족해 보일 수 있지만, 어차피 전체 배포를 한 번에 SharePoint 2010으로 변환하지 않을 것이므로 한 번에 한 영역에 대한 배포에 초점을 맞출 수 있습니다.
백업 확인
SharePoint 2010으로의 업그레이드를 시작하기 전 마지막 단계는 백업이 올바르게 작동하는지 확인하는 것입니다. 필자가 아는 사람 중에 평소에 서버를 열심히 백업해 왔다고 생각했는데 모두 소용 없었다는 사실을 힘들게 알게 된 사람이 있습니다. 여러분에게는 이런 일이 일어나지 않기를 바랍니다. 백업을 테스트하고 복원 가능한지 확인하십시오.
.jpg)
Brien Posey***는 Microsoft MVP이며 수천 개의 기사와 수십 개의 서적을 집필한 기술 관련 프리랜서 작가입니다. 문의 사항이 있으면 저자의 웹 사이트인 *brienposey.com을 방문해 보십시오.