초대형 데이터베이스 마이그레이션 모범 사례 살펴보기

• 11분

포함된 다음 지침은 실제 고객 프로젝트 및 이러한 프로젝트에서 얻은 지식을 기반으로 합니다. 이 지침에서는 과거에 실패한 시나리오를 확인합니다. UNIX 서버 또는 가상화된 서버를 R3load 내보내기 서버로 사용하지 말라는 권장 사항을 예로 들 수 있습니다.

• 내보내기 성능이 전체적인 가동 중지 시간을 결정하는 요인인 경우가 자주 있습니다. 현재 하드웨어는 4-5년이 넘은 것들이 많으며 업그레이드 비용이 엄청나게 많이 듭니다.
• 따라서 실현 가능한 최대 내보내기 성능을 얻는 것이 중요합니다.
• 이전 프로젝트는 UNIX 또는 가상화된 플랫폼에서 R3load 내보내기 성능을 조정하는 데 몇 주 또는 몇 달이 걸렸습니다. 결국 포기하고 Intel R3load 서버를 사용했습니다.
• 듀얼 소켓 상용 Intel 서버는 저렴하고 성능을 대폭 개선하며, 경우에 따라 UNIX 또는 가상화된 서버에서 가능한 사소한 튜닝 개선보다 수십 배 개선하기도 합니다.
• 고객은 기존 가상 머신 팜을 보유하고 있는 경우가 많지만 대부분은 최신 오프로드나 SR-IOV 기술을 지원하지 않습니다. VMware가 오래된 버전이거나 패치되지 않았거나 높은 네트워크 처리량과 짧은 대기 시간을 지원하도록 구성되지 않은 경우가 자주 있습니다. R3load 내보내기 서버에는 매우 빠른 스레드 성능과 높은 네트워크 처리량이 필요합니다. R3load 내보내기 서버가 10-15시간 동안 거의 100% CPU 및 네트워크 사용률에서 실행될 수 있습니다. 이는 대부분의 VMware 팜에서는 일반적인 사용 사례가 아니며, 대부분의 VMware 배포는 R3load와 같은 워크로드를 처리하도록 설계되지 않았습니다.

모범 사례

• 현재 SAP 환경을 조사하고 인벤토리를 작성합니다. SAP 지원 팩 수준을 파악하고 대상 DBMS를 지원하려면 패치가 필요한지 확인합니다. 일반적으로 운영 체제 호환성은 SAP 커널에 따라 결정되고 DBMS 호환성은 SAP_BASIS 패치 수준에 따라 결정됩니다.
• SMIGR_CREATE_DDL 업데이트와 같이 원본 시스템에서 적용해야 하는 SAP OSS 노트 목록을 작성합니다. Azure로 마이그레이션하는 동안 큰 변경을 방지하려면 원본 시스템에서 SAP 커널을 업그레이드하는 것이 좋습니다(예: 시스템에서 이전 7.41 커널을 실행하는 경우 마이그레이션 중에 큰 변경을 방지하기 위해 원본 시스템에서 최신 7.45로 업데이트).
• 고가용성 및 재해 복구 솔루션을 개발하고 문서화합니다. 설명서에서 솔루션을 DB 계층, ASCS 계층 및 SAP 애플리케이션 서버 계층으로 분리해야 합니다. TREX 또는 liveCache와 같은 독립 실행형 솔루션에는 별도의 솔루션이 필요할 수 있습니다.
• Azure 가상 머신 형식과 스토리지 구성을 자세히 설명하는 크기 조정 및 구성 문서를 개발합니다. 프리미엄 디스크 수, 데이터 파일 수, 디스크에 데이터 파일을 분산하는 방법, 저장소 공간 사용, NTFS 형식 크기(64kb)에 대해 자세히 설명합니다. 또한 메모리 설정, 최대 병렬화 정도, 추적 플래그와 같은 백업/복원 및 DBMS 구성을 문서화합니다.
• 가상 네트워크, 서브넷, NSG 및 UDR 구성을 포함하는 네트워크 디자인 문서를 개발합니다.
• 보안 및 강화 개념을 문서화하고 구현합니다. Internet Explorer를 제거하고, SAP 서비스 계정 및 서버용 Active Directory 컨테이너를 만들고, 제한된 수의 필수 포트를 제외한 모든 포트를 차단하는 방화벽 정책을 적용합니다.
• 패키지 및 테이블 분할 개념, R3load 수, SQL Server 추적 플래그, 정렬/비정렬, Oracle RowID 설정, SMIGR_CREATE_DDL 설정, Perfmon 카운터(예: BCP 행 수/초 및 BCP 처리량(kb)/초, CPU, 메모리), RSS 설정, 가속화된 네트워킹 설정, 로그 파일 구성, BPE 설정, TDE 구성에 대해 자세히 설명하는 OS/DB 마이그레이션 디자인 문서를 만듭니다.
• 각 테스트 주기에서 R3load 내보내기/가져오기 진행 상황을 보여주는 "플라이트 계획" 그래프를 만듭니다. 이렇게 하면 마이그레이션 팀이 튜닝 및 변경 후 R3load 내보내기 또는 가져오기 성능이 향상되었는지 확인할 수 있습니다. X축은 완료된 패키지 수이고, Y축은 경과한 시간입니다. 계획된 진행률을 실제 진행률 및 초기에 확인된 문제와 비교할 수 있으므로, 이 플라이트 계획은 프로덕션 마이그레이션 중에도 중요합니다.
• 성능 테스트 계획을 작성합니다. 상위 20개 온라인 보고서, 일괄 처리 작업 및 인터페이스를 파악합니다. 입력 매개 변수(예: 날짜 범위, 영업 사무실, 공장, 회사 코드 등) 및 런타임을 원래 원본 시스템에 문서화합니다. Azure의 런타임과 비교합니다. 성능 차이가 있는 경우 SAT, ST05 및 기타 SAP 도구를 실행하여 비효율적인 명령문을 파악합니다.
• 배포 및 구성을 감사하고 클러스터 시간 제한, 커널, 네트워크 설정, NTFS 형식 크기가 모두 설계 문서와 일치하는지 확인합니다. 90초마다 기본 상태 매개 변수를 기록하도록 중요한 서버에서 perfmon 카운터를 설정합니다. SAP 서버가 별도의 AD 컨테이너에 있고 컨테이너에 방화벽 구성을 사용하여 그룹 정책이 적용되었는지 확인합니다.
• 리드 OS/DB 마이그레이션 컨설턴트의 라이선스가 있는지 확인합니다. 컨설턴트 이름, s-사용자 및 인증 날짜를 요청합니다. BC-INS-MIG에 OSS 메시지를 열고 SAP에 컨설턴트가 최신이고 사용이 허가되었는지 확인해 달라고 요청합니다.
• 가능하다면 전체 프로젝트 팀을 하나의 물리적 위치 내에서 VLDB 마이그레이션 프로젝트와 연결하고 여러 대륙 및 표준 시간대에 걸쳐 지리적으로 분산되지 않도록 합니다.
• 적절한 대체 계획을 세우고 전체 일정에 포함하도록 합니다.
• R3load 내보내기 서버용으로 고속 스레드 카운트 Intel CPU 모델을 선택합니다. "절전" CPU 모델은 성능이 낮고 4소켓 서버를 사용하지 않으므로 사용하면 안 됩니다. Intel Xeon E5 8158이 좋은 예입니다.

문제 방지를 위한 모범 사례

• 내보내기를 맡을 컨설팅 조직과 가져오기를 맡을 컨설팅 조직을 따로 계약하지 마세요. 원본 시스템을 한 컨설팅 조직에서 아웃소싱 받아서 관리하는데, 고객은 Azure로 마이그레이션하고 파트너를 바꾸려는 경우가 있습니다. 내보내기 및 가져오기 튜닝과 구성이 긴밀하게 결합되어 있으므로, 이러한 작업을 서로 다른 조직에 할당하면 좋은 결과를 얻을 가능성이 낮습니다.
• 마이그레이션하고 가동하는 동안에는 Azure 하드웨어 리소스를 아끼지 마세요. Azure Virtual Machines는 분당 요금이 부과되며 크기를 쉽게 줄일 수 있습니다. VLDB 마이그레이션 중에는 사용 가능한 가장 강력한 가상 머신을 사용합니다. 고객들은 크기가 200~250% 초과하는 시스템에서 성공적으로 가동한 다음, 크기가 초과하는 시스템을 실행하는 동안 안정화되었습니다. 4~6주 동안 시스템 사용률을 모니터링한 후, 여분의 용량이 있는 가상 머신은 크기를 줄이거나 종료하여 비용을 절감합니다.