이 검사 목록은 SAP 애플리케이션을 Azure 서비스 제공 인프라로 이동하는 고객을 위해 작성되었습니다. 이 문서의 SAP 애플리케이션은 SAP NetWeaver, S/4HANA, BW, BW/4 등의 SAP 커널을 실행하는 SAP 제품을 나타냅니다. 프로젝트를 진행하는 동안 고객 및/또는 SAP 파트너는 검사 목록을 검토해야 합니다. 많은 검사가 프로젝트를 시작할 때 그리고 계획 단계에서 완료된다는 것을 기억해야 합니다. 배포가 완료된 후에는 배포된 Azure 인프라 또는 SAP 소프트웨어 릴리스에서 간단한 변경조차 복잡해질 수 있습니다.
프로젝트를 진행하는 동안 주요 마일스톤에서 검사 목록을 검토합니다. 이렇게 하면 작은 문제가 큰 문제로 확대되기 전에 미리 발견할 수 있습니다. 또한 필요한 변경 내용을 다시 엔지니어링하고 테스트하는 데 충분한 시간을 확보할 수 있습니다. 이 검사 목록을 전체 목록으로 간주해서는 안 됩니다. 상황에 따라 추가로 더 검사해야 할 수도 있습니다.
Azure와 무관한 작업은 이 검사 목록에 포함되어 있지 않습니다. 예를 들어 Azure 플랫폼이나 호스팅 공급자로 전환하는 동안 SAP 애플리케이션 인터페이스가 변경될 수도 있습니다. SAP 설명서 및 지원 정보에는 Azure에 한정되지 않고 전체 계획 검사 목록의 일부가 되어야 하는 추가 작업도 포함됩니다.
이 검사 목록은 이미 배포된 시스템에도 사용할 수 있습니다. 새 기능 또는 변경된 권장 사항이 환경에 적용될 수 있습니다. 따라서 검사 목록을 주기적으로 검토하여 Azure 플랫폼의 새로운 기능을 알아 두는 것이 유용합니다.
이 문서의 주 콘텐츠는 탭으로 구성되며 일반적인 프로젝트의 진행 순서를 따릅니다. 각 탭의 콘텐츠를 확인한 이후 이어지는 각 탭은 이전 단계에서 얻은 학습 및 수행한 작업을 기반으로 빌드하는 것이 좋습니다. 프로덕션 마이그레이션의 경우 프로덕션 탭만이 아닌 모든 탭의 콘텐츠를 고려해야 합니다. 일반적인 프로젝트 단계를 이 문서에 사용된 단계 정의와 매핑하는 데 도움이 되도록 아래 표를 참조하세요.
이 단계에서는 SAP 워크로드를 Azure 플랫폼으로 마이그레이션할 계획을 세웁니다. 많은 토픽을 다루는 Azure의 SAP 계획 가이드 및 SAP용 클라우드 채택 프레임워크와 같은 문서의 정보가 준비에 도움이 될 수 있습니다. 이 단계에서는 최소한 다음과 같은 문서를 만들고 아래와 같은 마이그레이션 요소를 정의하고 논의해야 합니다.
개략적인 디자인 문서
이 문서에는 다음 내용이 포함되어야 합니다.
SAP 구성 요소 및 애플리케이션의 현재 인벤토리와 Azure의 대상 애플리케이션 인벤토리
관련 당사자의 책임과 할당을 정의하는 RACI(책임 할당 매트릭스). 상위 수준에서 시작한 후, 계획 전체와 첫 번째 배포에서 점점 세부적으로 작업합니다.
많은 영향을 미치는 비즈니스 데이터를 Azure에서 실행하기 위한 보안 원칙. 데이터 보안에 대한 자세한 내용은 Azure 보안 설명서를 참조하세요.
기술 디자인 문서에서 파일 시스템 크기 및 레이아웃으로 더 구체화해야 하는 블록 디바이스(관리 디스크) 및 공유 파일 시스템(예: Azure Files 또는 Azure NetApp Files)을 다루는 스토리지 전략이 필요합니다.
기술 디자인 문서
이 문서에는 다음 내용이 포함되어야 합니다.
SAP/비SAP 애플리케이션 및 서비스를 보여 주는 솔루션의 블록 다이어그램
비즈니스 문서 양을 기반으로 하는 SAP Quicksizer 프로젝트. Quicksizer의 출력은 Azure의 컴퓨팅, 스토리지 및 네트워킹 구성 요소에 매핑됩니다. SAP Quicksizer 대신 원본 SAP 시스템의 현재 워크로드를 기반으로 부지런히 크기를 조정합니다. DBMS 워크로드 보고서, SAP EarlyWatch 보고서, 컴퓨팅 및 스토리지 성능 지표 등 사용 가능한 정보를 고려합니다.
비즈니스 연속성 및 재해 복구 아키텍처
OS, DB, 커널 및 SAP 지원 팩 버전에 대한 자세한 정보. SAP NetWeaver 또는 S/4HANA에서 지원되는 모든 OS 릴리스가 Azure VM에서도 반드시 지원되는 것은 아닙니다. DBMS 릴리스도 마찬가지입니다. 다음 소스를 확인하여 SAP와 Azure를 지원하도록 SAP 릴리스, DBMS 릴리스 및 OS 릴리스의 버전을 맞추고 필요한 경우 업그레이드합니다. SAP 및 Microsoft의 완벽한 지원을 받으려면 SAP 및 Azure에서 지원하는 릴리스 조합이 있어야 합니다. 필요한 경우 소프트웨어 구성 요소 중 일부를 업그레이드할 계획을 세워야 합니다. 지원되는 SAP, OS 및 DBMS 소프트웨어에 대한 자세한 내용은 다음 문서에 설명되어 있습니다.
SAP Note 2039619. 이 노트에는 Azure의 Oracle 지원 매트릭스가 정의되어 있습니다. Oracle은 Azure에서 SAP 워크로드에 대한 게스트 운영 체제로 Windows 및 Oracle Linux만 지원합니다. 이 지원 문서는 Oracle 클라이언트를 포함하는 한 SAP 인스턴스를 실행하는 SAP 애플리케이션 계층에도 적용됩니다.
SAP HANA를 지원하는 Azure VM 목록은 SAP 웹 사이트에 나와 있습니다. 각 항목의 세부 정보에는 지원되는 OS 버전을 비롯한 세부 사항 및 요구 사항이 포함되어 있습니다. SAP Note 2235581의 내용과 최신 OS 버전이 일치하지 않을 수 있습니다.
Azure 지역의 재해 복구는 다른 DBMS 공급업체에서 제공하는 솔루션을 검토하세요. 대부분은 비동기 복제 또는 로그 전달을 지원합니다.
SAP 애플리케이션 계층의 경우 비즈니스 재발 테스트 시스템(프로덕션 배포의 복제본인 것이 가장 좋음)을 동일한 Azure 지역에서 실행할 것인지 아니면 DR 지역에서 실행할 것인지 결정합니다. 후자인 경우 해당 비즈니스 재발 시스템을 프로덕션 배포의 DR 대상으로 지정할 수 있습니다.
SAP 데이터를 Azure로 마이그레이션하기 위한 데이터 감소 및 데이터 마이그레이션 계획. SAP NetWeaver 시스템의 경우 SAP는 대량의 데이터 볼륨을 제한하는 방법에 대한 지침을 제공합니다. SAP ERP 시스템의 데이터 관리 방법은 이 SAP 가이드를 참조하세요. 일부 콘텐츠는 NetWeaver 및 S/4HANA 시스템에도 일반적으로 적용됩니다.
자동화된 배포 방법. 많은 고객이 PowerShell, CLI, Ansible, Terraform의 조합을 사용하여 스크립트로 시작합니다.
Microsoft에서 개발한 SAP 배포 자동화용 솔루션은 다음과 같습니다.
고객, 시스템 통합업체, Microsoft 및 기타 관련 당사자 간의 정기적인 디자인 및 배포 검토 케이던스를 정의합니다.
파일럿 단계(강력 권장)
프로젝트를 계획하고 준비하는 동안 또는 그 전에 파일럿을 실행할 수 있습니다. 파일럿 단계를 사용하여 계획 및 준비 단계에서 작성된 방법과 디자인을 테스트할 수도 있습니다. 그리고 파일럿 단계를 확장하여 개념 증명으로 만들 수 있습니다.
파일럿 배포 중에 전체 HADR 솔루션 및 보안 디자인을 설정하고 유효성을 검사하는 것이 좋습니다. 어떤 고객은 이 단계에서 확장성 테스트를 수행합니다. 또 어떤 고객은 SAP 샌드박스 시스템 배포를 파일럿 단계로 사용합니다. 여기서는 파일럿을 실행하기 위해 Azure로 마이그레이션하려는 시스템을 이미 식별했다고 가정합니다.
Azure로 데이터 전송을 최적화합니다. 가장 좋은 선택은 시나리오에 따라 달라집니다. 데이터베이스 복제에 비공개 연결이 필요한 경우 ExpressRoute 회로에 충분한 대역폭이 있다면 Azure ExpressRoute가 가장 빠릅니다. 기타 다른 시나리오에서는 인터넷으로 전송하는 것이 더 빠릅니다. 필요에 따라 Azure의 비공개 연결을 위해 전용 마이그레이션 VPN을 사용합니다. 파일럿 중에 모든 마이그레이션 네트워크 경로는 향후 프로덕션 시스템의 사용을 미러하여, 이미 Azure에서 실행 중인 워크로드(SAP 또는 비SAP)에 미치는 영향을 없애야 합니다.
데이터 내보내기 및 가져오기가 수반되는 다른 유형의 SAP 마이그레이션의 경우 내보내기 및 가져오기 단계를 테스트하고 최적화해야 합니다. 대규모 SAP 환경 마이그레이션의 경우 사용 가능한 모범 사례를 참조하세요. 원본 및 대상 SAP 릴리스, DBMS에 따라 또는 마이그레이션과 릴리스 업그레이드, 유니코드, S/4HANA 변환 등의 다른 작업을 결합하는 경우 마이그레이션 시나리오에 적합한 도구를 사용합니다. SAP는 별도의 서비스로 사용할 수 있는 가동 중지 시간을 최소화하는 다른 방법 외에도 마이그레이션 모니터/SWPM, SAP DMO 또는 시스템 이동 옵션이 있는 DMO를 제공합니다. 시스템 이동 옵션이 있는 SAP DMO의 최신 릴리스에서는 인터넷으로 데이터를 전송하는 azcopy 사용 역시 지원되므로 기본적으로 가장 빠른 네트워크 경로를 사용할 수 있습니다.
VLDB(초대형 데이터베이스)를 Azure for SAP로 마이그레이션
기술 유효성 검사
컴퓨팅/VM 유형
SAP 지원 노트, SAP HANA 하드웨어 디렉터리 및 SAP PAM의 리소스를 다시 검토합니다. Azure를 지원하는 VM, 이러한 VM을 지원하는 OS 릴리스, 지원되는 SAP 및 DBMS 릴리스를 일치시켜야 합니다.
계획 단계에서 선택한 VM 유형의 최대 스토리지 및 네트워크 처리량에 대한 Azure VM의 크기 조정을 평가하고 테스트해야 합니다. VM 성능 제한의 세부 정보를 사용할 수 있습니다. 스토리지의 경우 크기 조정을 위해 캐시되지 않은 최대 디스크 처리량 제한을 고려하는 것이 중요합니다. 디스크 및 VM 수준 버스팅의 크기 조정 및 임시 효과를 신중하게 고려합니다.
Azure에서 고유한 OS 이미지를 만들지, 아니면 Azure Compute Gallery(이전의 Shared Image Gallery)의 이미지를 사용할 것인지 테스트를 거친 후 결정합니다. Azure Compute Gallery의 이미지를 사용하는 경우에는 OS 공급업체와 맺은 지원 계약을 반영하는 이미지를 사용해야 합니다. 일부 OS 공급업체의 경우 Azure Compute Gallery를 사용하여 고유한 라이선스 이미지를 가져올 수 있습니다. 다른 OS 이미지의 경우 Azure의 견적 가격에 지원이 포함됩니다.
자체 OS 이미지를 사용하면 보안 에이전트, 강화 및 사용자 지정과 같은 필수 엔터프라이즈 종속성을 이미지에 직접 저장할 수 있습니다. 이렇게 하면 해당 이미지가 모든 VM과 함께 즉시 배포됩니다. 사용자 고유의 OS 이미지를 만들려는 경우 다음 문서에서 설명서를 찾을 수 있습니다.
OS 이미지를 선택하면 Azure VM 생성 유형이 결정됩니다. Azure는 Hyper-V 1세대 및 2세대 VM을 모두 지원합니다. 일부 VM 제품군은 2세대로만 사용할 수 있으며, 일부 VM 제품군은 Azure가 두 세대를 모두 허용하더라도 2세대로만 SAP를 사용하도록 인증됩니다(SAP Note 1928533). SAP 환경의 모든 VM에 2세대 VM을 사용하는 것이 좋습니다.
다른 DBMS 형식의 경우 일반 SAP 관련 DBMS 설명서 및 첫 번째 문서에 언급되는 DBMS 관련 설명서를 확인합니다. 데이터베이스 데이터 및 로그 영역에 Premium Storage(v1 또는 v2)가 있는 여러 디스크에 디스크 스트라이프를 사용합니다. Linux에서는 'lvs -a -o+lv_layout,lv_role,stripes,stripe_size,devices'명령을 사용하여 lvm 디스크 스트라이프가 활성 상태이고 올바른 스트라이프 크기인지 확인합니다. Windows에서는 스토리지 공간 속성을 참조하세요.
SAP Note 500235 및 1100926에 따라 SAP 애플리케이션 계층 VM과 DBMS VM 간의 네트워크 대기 시간을 테스트하고 평가합니다. SAP의 niping 외에도 tcp 대기 시간 측정에 sockperf 또는 ethr과 같은 도구를 사용할 수 있습니다. SAP Note 1100926의 네트워크 대기 시간 지침에 따라 결과를 평가합니다. 네트워크 대기 시간이 보통이거나 정상 범위에 있어야 합니다.
일반적으로 데이터베이스 서버에 사용되는 높은 vCPU VM에서 네트워크 처리량을 최적화합니다. 이는 HANA 스케일 아웃 및 대규모 SAP 시스템에 특히 중요합니다. 최적화를 위해 이 문서의 권장 사항을 따릅니다.
최적의 네트워크 대기 시간을 위해서는 근접 배치 시나리오 문서의 지침을 따르는 것이 좋습니다. 영역 또는 영역 간 배포 패턴에는 근접 배치 그룹을 사용하지 않습니다.
OS 패치 리포지토리, 배포 도구 또는 서비스 엔드포인트와 같은 필요한 인터넷 엔드포인트로 SAP 환경에서 올바른 가용성, 라우팅 및 보안 액세스를 확인합니다. 마찬가지로 SAP 환경에서 SAP Fiori 또는 SAProuter와 같이 공개적으로 액세스할 수 있는 서비스를 제공하는 경우 연결 가능하고 보안이 유지되는지 확인합니다.
고가용성 및 재해 복구 배포
클러스터된 환경에는 항상 표준 부하 분산 장치를 사용합니다. 기본 부하 분산 장치는 곧 사용 중지됩니다.
여러 영역에 걸쳐 있는지, 단일 영역 내에 상주하는지, 영역 없는 지역에서 작동하는지 등 Azure 지역 내에서 기본 설정하는 시스템 구성에 따라 적합한 배포 옵션을 선택합니다.
지역 배포에서 수동 복제를 사용하여 고가용성을 위해 SAP Central Services 및 DBMS 계층을 보호하려면 SAP Central Services에 대한 두 개의 노드를 하나의 별도 가용성 집합에 배치하고 두 개의 DBMS 노드를 다른 가용성 집합에 배치합니다. 가용성 집합 내에서 애플리케이션 VM 역할을 혼합해선 안 됩니다.
영역 간 배포의 경우 FD=1인 유연한 확장 집합을 사용하여 시스템을 구성하고 활성 및 수동 중앙 서비스 노드와 DBMS 계층을 두 개의 서로 다른 가용성 영역에 배포합니다. 서로 간에 대기 시간이 가장 짧은 가용성 영역 2개를 사용합니다.
영역 간 배포의 경우 표준 가용성 영역 배포보다 FD=1인 유연한 확장 집합을 사용하는 것이 좋습니다.
Linux 게스트 운영 체제와 함께 Azure Load Balancer를 사용하는 경우 Linux 네트워크 매개 변수 net.ipv4.tcp_timestamps가 0으로 설정되었는지 확인합니다. 이 권장 사항은 이전 SAP Note 2382421 버전의 권장 사항과 충돌합니다. 이제 SAP 노트는 Azure 부하 분산 장치에 사용하려면 이 매개 변수를 0으로 설정해야 한다고 업데이트되었습니다.
시간 제한 설정
SAP 인스턴스의 SAP NetWeaver 개발자 추적을 검사하고 큐에 넣기 서버와 SAP 작업 프로세스 간 연결이 끊어지지 않았는지 확인합니다. 이러한 연결 끊김은 다음 두 레지스트리 매개 변수를 설정하여 방지할 수 있습니다.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. 자세한 내용은 KeepAliveTime을 참조하세요.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. 자세한 내용은 KeepAliveInterval을 참조하세요.
온-프레미스 SAP GUI 인터페이스와 Azure에 배포된 SAP 애플리케이션 계층 간 GUI 시간 초과를 방지하려면 default.pfl 또는 인스턴스 프로필에서 다음 매개 변수가 설정되었는지 확인합니다.
rdisp/keepalive_timeout = 3600
rdisp/keepalive = 20
SAP 큐에 넣기 프로세스와 SAP 작업 프로세스 간에 설정된 연결이 해제되지 않도록 하려면 enque/encni/set_so_keepalive 매개 변수를 true로 설정해야 합니다. 또한 SAP Note 2743751을 참조하세요.
Windows 장애 조치(failover) 클러스터 구성을 사용하는 경우 응답하지 않는 노드에 반응하는 시간이 Azure에 대해 올바르게 설정되어 있는지 확인합니다. 장애 조치(Failover) 클러스터 네트워크 임계값 조정 문서에는 매개 변수 및 매개 변수가 장애 조치(Failover) 민감도에 미치는 영향이 나와 있습니다. 클러스터 노드가 동일한 서브넷에 있다고 가정할 경우 다음 매개 변수를 변경해야 합니다.
SameSubNetDelay = 2000(“하트비트” 사이의 밀리초 수)
SameSubNetThreshold = 15(연속으로 누락된 최대 하트비트 수)
RoutingHistorylength = 30(초, 2,000ms * 하트비트 15개 = 30s)
OS 설정 또는 패치
SAP에서 HANA를 실행하려면 SAP의 비Azure 관련 설명서 및 기타 지원 참고 외에도 다음 노트와 설명서를 참조하세요.
Azure 전용 SAP Note는 SAP 지원 구성 요소 BC-OP-NT-AZR 또는 BC-OP-LNX-AZR로 연결됩니다. 업데이트된 솔루션이 포함된 노트를 자세히 살펴봅니다.
NotMyFault(Windows)와 같은 도구를 사용하거나 운영 체제를 패닉 모드로 전환하거나 ifdown(Linux)으로 네트워크 인터페이스를 사용하지 않도록 설정하여 장애 조치(failover) 상황을 시뮬레이션합니다. 이 단계는 장애 조치(failover) 구성이 설계대로 작동하는지 파악하는 데 도움이 됩니다.
장애 조치(failover)를 실행하는 데 걸리는 시간을 측정합니다. 시간이 너무 오래 걸리면 다음을 고려합니다.
SUSE Linux의 경우 Azure Fence 에이전트 대신 SBD 디바이스를 사용하여 장애 조치(failover) 속도를 높입니다.
SAP HANA의 경우 데이터 다시 로드 시간이 너무 오래 걸리면 더 많은 스토리지 대역폭을 프로비전하는 것이 좋습니다.
백업/복원 순서와 타이밍을 테스트하고 필요한 경우 수정합니다. 백업 시간이 충분한지 확인합니다. 복원 및 시간 복원 작업도 테스트해야 합니다. RTO가 데이터베이스 또는 VM 복원 프로세스에 의존하는 경우 복원 시간이 RTO SLA 내에 있는지 확인합니다.
지역 간 DR 기능 및 아키텍처를 테스트하고 RPO 및 RTO가 예상과 일치하는지 확인합니다.
보안 검사
Azure RBAC(역할 기반 액세스 제어) 아키텍처의 유효성을 테스트합니다. 여러 팀의 액세스 및 사용 권한을 제한하려면 의무를 분리해야 합니다. 예를 들어 SAP 기본 팀 구성원은 VM을 배포하고 Azure Storage의 디스크를 지정된 Azure 가상 머신에 할당할 수 있어야 합니다. 그러나 SAP 기본 팀은 고유의 가상 네트워크를 만들거나 기존 가상 네트워크의 설정을 변경할 수 없어야 합니다. 네트워크 팀의 구성원은 VM을 SAP 애플리케이션 및 DBMS VM이 실행되는 가상 네트워크에 배포할 수 없어야 합니다. 또한 네트워크 팀의 구성원은 VM 특성을 변경하거나 VM 또는 디스크를 삭제할 수 없어야 합니다.
암호화해야 하는 모든 리소스가 암호화되는지 확인합니다. 인증서를 백업하고, 해당 인증서를 저장 및 액세스하고, 암호화된 엔터티를 복원하는 프로세스를 정의하고 구현합니다.
스토리지 암호화의 경우 기본적으로 관리 디스크, Azure Files 및 Azure NetApp Files를 포함하여 Azure의 SAP에 사용되는 모든 스토리지 서비스가 SSE-PMK(플랫폼 관리형 키를 사용하는 서버 쪽 암호화)를 사용하도록 설정됩니다. 고객 소유 키 순환에 필요한 경우 고객 관리형 키를 사용한 키 관리를 고려할 수 있습니다.
M 시리즈 제품군 Linux VM에서 성능상의 이유로 호스트 기반 서버 쪽 암호화를 사용하도록 설정하면 안 됩니다.
‘SAP용’ OS 이미지는 지원되지 않으므로 Linux에서 SAP와 Azure Disk Encryption을 함께 사용하면 안 됩니다.
Azure의 SAP를 사용하는 대다수 고객은 데이터베이스 네이티브 암호화를 배포하여 DBMS 데이터 및 백업을 보호합니다. TDE(투명한 데이터 암호화)는 일반적으로 눈에 띄는 성능 오버헤드가 없으며 보안이 크게 향상되므로 사용을 고려하는 것이 좋습니다. 암호화 키 관리 및 위치를 보호해야 합니다. 데이터베이스 암호화는 VM 내에서 발생하며 SSE와 같은 스토리지 암호화와 독립적으로 수행됩니다.
성능 테스트 SAP에서 SAP 추적 및 측정을 기반으로 다음과 같은 비교를 수행합니다.
현재 온-프레미스 시스템의 인벤토리 및 기준.
SAR 보고서/Perfmon.
STAT 추적 상위 10개 온라인 보고서.
일괄 작업 기록 수집.
집중 테스트로 비즈니스 프로세스 성능을 확인합니다. 성능 차이 문제를 해결할 때에만 초반이나 진공 상태에서 하드웨어 KPI를 비교해선 안 됩니다.
해당하는 경우 상위 10개 온라인 보고서를 현재 구현과 비교합니다.
해당하는 경우 상위 10개 일괄 작업을 현재 구현과 비교합니다.
인터페이스를 통해 SAP 시스템으로 전송되는 데이터를 비교합니다. 온-프레미스에서 Azure로 전송되는 경우처럼 서로 다른 위치 간에 데이터가 전송되는 것을 알 고 있는 인터페이스에 집중합니다.
비프로덕션 단계
이 단계에서는 성공적인 파일럿 또는 POC(개념 증명) 후에 비프로덕션 SAP 시스템을 Azure에 배포하기 시작한다고 가정합니다. POC 과정에서 배우고 경험한 모든 것을 이 배포에 통합합니다. POC에 대해 나열된 모든 조건과 단계는 이 배포에도 적용됩니다.
이 단계에서는 일반적으로 개발 시스템, 단위 테스트 시스템 및 비즈니스 재발 테스트 시스템을 Azure에 배포합니다. 향후 프로덕션 시스템에 필요하므로 단일 SAP 애플리케이션 라인에 포함된 하나 이상의 비프로덕션 시스템에 완전한 고가용성 구성을 적용하는 것이 좋습니다. 다음은 이 단계에서 완료해야 하는 몇 가지 추가 작업입니다.
이전 플랫폼의 시스템을 Azure로 이동하기 전에 CPU 사용량, 스토리지 처리량 및 IOPS 데이터와 같은 리소스 소비량 데이터를 수집합니다. 특히 DBMS 계층 단위에서 이 데이터를 수집하지만 애플리케이션 계층 단위에서도 수집합니다. 또한 네트워크 및 스토리지 대기 시간을 측정합니다. 캡처된 데이터를 사용하여 크기 및 디자인을 조정합니다. syststat, KSAR, nmon, Excel용 nmon analyzer와 같은 도구를 사용하여 사용량이 많은 기간 동안 리소스 사용률을 캡처하고 표시해야 합니다.
시스템의 가용성 사용 시간 패턴을 기록합니다. 목표는 비프로덕션 시스템을 연중무휴로 사용할 수 있어야 하는지 여부 또는 주 또는 월의 특정 단계 동안 종료해도 되는 비프로덕션 시스템이 있는지 파악하는 것입니다.
OS 이미지 선택, VM 생성(SAP 환경 전체의 2세대) 및 OS 패치 전략을 다시 평가합니다.
Microsoft 지원 계약에 대한 SAP 지원 요구 사항을 이행해야 합니다. SAP Note 2015553을 참조하세요.
Note 1928533과 같은 Azure 관련 SAP Note에서 새 VM SKU 또는 새로 지원되는 OS 및 DBMS 릴리스가 있는지 확인합니다. 최고의 가격 대비 성능을 제공하는 VM을 배포할 수 있도록 새 VM 유형의 가격을 이전 VM 유형의 가격과 비교합니다.
SAP 지원 노트, SAP HANA 하드웨어 디렉터리 및 SAP PAM을 다시 확인합니다. Azure를 지원하는 VM, 이러한 VM을 지원하는 OS 릴리스, 지원되는 SAP 및 DBMS 릴리스가 변경되지 않았는지 확인합니다.
SAP 웹 사이트에서 Azure의 새로운 HANA 인증 SKU를 확인합니다. 새 SKU의 가격 책정을 사용하려는 가격 책정과 비교합니다. 최종적으로 가장 좋은 가격 대비 성능을 제공하는 제품을 사용하도록 변경해야 합니다.
새 VM 유형을 사용하고 원하는 새 Azure 기능을 통합하도록 배포 자동화 프레임워크를 조정합니다.
인프라를 배포한 후 SAP Note 500235에 따라 SAP 애플리케이션 계층 VM 및 DBMS VM 간의 네트워크 대기 시간을 테스트하고 평가합니다. SAP Note 1100926의 네트워크 대기 시간 지침에 따라 결과를 평가합니다. 네트워크 대기 시간이 보통이거나 정상 범위에 있어야 합니다. Niping, sockperf 또는 ethr과 같은 도구를 사용하는 것 외에도 스케일 아웃 또는 시스템 복제를 위해 HANA VM 간의 네트워크 측정에 SAP의 HCMT 도구를 사용합니다.
시스템 복사 기능 및 프로세스를 시험합니다. 목표는 개발 시스템 또는 테스트 시스템을 쉽게 복사하도록 하여 프로젝트 팀이 새 시스템을 빠르게 얻을 수 있게 만드는 것입니다.
팀의 Azure 역할 기반 액세스, 권한 및 프로세스를 최적화하여 의무를 분리합니다. 그와 동시에 모든 팀이 Azure 인프라에서 맡은 작업을 수행할 수 있는지 확인합니다.
고가용성 및 재해 복구 절차를 연습, 테스트 및 문서화하여 직원이 이러한 작업을 실행할 수 있도록 합니다. 단점을 파악하고 배포에 통합하려는 새 Azure 기능을 조정합니다.
프로덕션 준비 단계
이 단계에서는 비프로덕션 배포 중에 경험하고 배운 내용을 수집하고 향후 프로덕션 배포에 적용합니다.
Azure로 이동하기 전에 프로덕션 시스템의 모든 필수 SAP 릴리스 업그레이드를 완료합니다.
프로덕션 시스템의 마이그레이션 이후에 수행해야 하는 기능 및 비즈니스 테스트를 비즈니스 소유자와 협의합니다.
이러한 테스트를 현재 호스팅 위치의 원본 시스템으로 완료해야 합니다. 시스템이 Azure로 이동된 후 첫 번째 테스트를 수행하지 않도록 합니다.
프로덕션 시스템을 Azure로 마이그레이션하는 프로세스를 테스트합니다. 같은 기간에 모든 프로덕션 시스템을 Azure로 이동하지 않는 경우 동일한 호스팅 위치에 있어야 하는 프로덕션 시스템 그룹을 작성합니다. 연결된 비SAP 애플리케이션 및 인터페이스를 포함한 데이터 마이그레이션을 테스트합니다.
다음은 몇 가지 일반적인 방법입니다.
Azure에서 데이터베이스 콘텐츠를 시드하고 동기화하려면 백업/복원 등의 DBMS 방법과 SQL Server Always On, HANA 시스템 복제 또는 로그 전달을 함께 사용합니다.
백업/복원은 좀 더 작은 데이터베이스에 사용합니다.
마이그레이션을 이동하거나 SAP 릴리스 업그레이드와 결합 및/또는 HANA로 이동하려는 경우 지원되는 시나리오에 SAP DMO 프로세스를 사용합니다. 원본 DBMS와 대상 DBMS 간의 모든 조합이 지원되는 것은 아닙니다. 자세한 내용은 다양한 DMO 릴리스의 관련 SAP 지원 노트를 참조하세요. 예를 들어, SUM 2.0 SP15의 DMO(데이터베이스 마이그레이션 옵션)를 참조할 수 있습니다.
백업 또는 SAP 내보내기 파일을 이동해야 하는 경우 인터넷을 통한 데이터 전송과 ExpressRoute를 통한 데이터 전송 중 어떤 방식의 처리량이 더 높은지 테스트합니다. 인터넷을 통해 데이터를 이동하는 경우 향후 프로덕션 시스템을 위해 필요한 네트워크 보안 그룹/애플리케이션 보안 그룹 규칙 중 일부를 변경해야 할 수 있습니다.
이전 플랫폼에서 Azure로 시스템을 이동하기 전에 리소스 사용 데이터를 수집합니다. 유용한 데이터로는 CPU 사용량, 스토리지 처리량 및 IOPS 데이터가 있습니다. 특히 DBMS 계층 단위에서 이 데이터를 수집하지만 애플리케이션 계층 단위에서도 수집합니다. 또한 네트워크 및 스토리지 대기 시간을 측정합니다.
SAP Note와 필요한 OS 설정, SAP HANA 하드웨어 디렉터리 및 SAP PAM을 다시 확인합니다. Azure를 지원하는 VM, 이러한 VM을 지원하는 OS 릴리스, 지원되는 SAP 및 DBMS 릴리스가 변경되지 않았는지 확인합니다.
가장 최근에 결정한 VM 유형 및 Azure 기능을 고려하도록 배포 자동화 프레임워크를 업데이트합니다.
계획된 Azure 유지 관리 이벤트에 대응하기 위한 플레이북을 만듭니다. 계획된 유지 관리를 위해 시스템 및 VM을 다시 부팅해야 하는 순서를 결정합니다.
고가용성 및 재해 복구 절차를 연습, 테스트 및 문서화하여 직원이 마이그레이션 도중 및 실시간 의사 결정 직후에 이러한 작업을 실행할 수 있도록 합니다.
라이브로 전환 단계
라이브 단계 중에는 이전 단계에서 개발한 플레이북을 따라야 합니다. 테스트하고 연습한 단계를 실행합니다. 구성 및 프로세스에서 갑작스러운 변경을 피합니다. 또한 다음 단계를 완료합니다.
Azure Portal 모니터링 및 기타 모니터링 도구가 작동하는지 확인합니다. 인프라 모니터링을 위해 Azure Monitor와 같은 Azure 도구를 사용합니다. OS와 애플리케이션 KPI의 조합에 SAP용 Azure Monitor를 사용하면 실시간으로 전환 도중과 후에 모든 요소를 하나의 대시보드에 통합하여 가시성을 확보할 수 있습니다.
운영 체제 핵심 성과 지표는 다음을 참조합니다.
Linux에서는 sysstat 도구가 설치되어 있고 정기적으로 세부 정보를 캡처하는지 확인합니다.
데이터 마이그레이션 후 비즈니스 소유자와 합의한 모든 유효성 검사 테스트를 수행합니다. 원래 원본 시스템에 대한 결과가 있는 경우에만 유효성 검사 테스트 결과를 수락합니다.
인터페이스가 작동하는지 여부 및 다른 애플리케이션이 새로 배포한 프로덕션 시스템과 통신할 수 있는지 여부를 확인합니다.
SAP 트랜잭션 STMS를 통해 전송 및 수정 시스템을 확인합니다.
시스템이 프로덕션용으로 출시되면 데이터베이스 백업을 수행합니다.
시스템이 프로덕션용으로 출시되면 SAP 애플리케이션 계층 VM의 VM 백업을 수행합니다.
현재는 라이브 단계가 아니지만 이 라이브 단계 동안 Azure로 이동한 SAP 시스템과 통신하는 SAP 시스템의 경우 SM51에서 호스트 이름 버퍼를 다시 설정해야 합니다. 그러면 Azure로 이동한 애플리케이션 인스턴스의 이름과 연결된 이전에 캐시한 IP 주소가 제거됩니다.
프로덕션 후
이 단계에서는 시스템을 모니터링, 운영 및 관리합니다. SAP의 관점에서 보면, 이전 호스팅 위치에서 완료했어야 했던 일반적인 작업이 적용됩니다. 또한 다음과 같은 Azure 관련 작업을 완료합니다.
높은 요금이 부과된 시스템의 Azure 청구서를 검토합니다. FinOps 문화를 설치하고 조직의 Azure 비용 최적화 기능을 빌드합니다.
VM 및 스토리지 쪽에서 가격/성능 효율을 최적화합니다.
Azure의 SAP가 안정화되면 지속적인 크기 조정 및 용량 검토 문화로 초점을 전환해야 합니다. 오랜 기간에 걸쳐 크기를 조정하는 온-프레미스와 달리 정확한 크기 조정은 Azure의 SAP 워크로드를 실행할 때 주어지는 주요 이점이며, 부지런한 용량 계획이 핵심이 될 것입니다.
시스템을 종료할 수 있는 시간을 최적화합니다.
Azure에서 솔루션이 안정화되면 종량제 상용 모델에서 벗어나 Azure Reserved Instances를 활용하는 것이 좋습니다.
정기적인 재해 복구 훈련을 계획하고 실행합니다.
기술 발전의 이점을 얻도록 자체 로드맵을 Microsoft의 Azure의 SAP 로드맵에 맞추기 위해 '에버그리닝'을 중심으로 전략을 정의하고 구현합니다.
Azure의 SAP 인프라 검사 목록
인프라 및 애플리케이션을 배포한 후 각 마이그레이션이 시작되기 전에 다음의 유효성을 검사합니다.
올바른 VM 유형을 올바른 특성 및 스토리지 구성으로 배포했습니다.
VM이 최신 OS, DBMS, SAP 커널 릴리스 및 패치를 갖추었으며, OS, DB, SAP 커널이 환경 전체에서 균일합니다.
Azure NetApp Files의 경우 올바른 탑재 옵션이 사용되고 볼륨 크기가 올바른 스토리지 계층에서 적절하게 조정됩니다.
모든 SMB 또는 NFS 볼륨 또는 공유에 Azure 서비스(Azure Files 또는 Azure NetApp Files)를 사용합니다. NFS 볼륨 또는 SMB 공유는 해당 SAP 환경 또는 개별 SAP 시스템에서 연결할 수 있습니다. NFS/SMB 서버의 네트워크 라우팅은 필요한 경우 프라이빗 엔드포인트를 사용하여 개인 네트워크 주소 공간을 통과합니다.
SAP NetWeaver 또는 ABAP Platform을 기반으로 하는 SAP 애플리케이션과 SAP 시스템의 DBMS 계층 간의 통신 경로에는 네트워크 가상 어플라이언스가 없습니다.
SAP 고가용성 구성 요소의 모든 부하 분산 장치는 부동 IP 및 HA 포트가 활성화된 표준 부하 분산 장치를 사용합니다.
SAP 애플리케이션 및 DBMS VM은 하나의 가상 네트워크 또는 직접 피어링된 가상 네트워크의 동일하거나 다른 서브넷에 배치됩니다.
애플리케이션 보안 그룹 및 네트워크 보안 그룹 규칙이 원하고 계획한 대로 통신을 허용하고 필요한 경우 통신을 차단할 수 있습니다.
앞에서 설명된 시간 제한이 올바르게 설정되었습니다.
근접 배치 그룹을 사용하는 경우 가용성 집합 및 해당 VM이 올바른 PPG에 배포되었는지 검사합니다.
SAP Note 500235 및 1100926에 설명된 대로 SAP 애플리케이션 계층 VM과 DBMS VM 간의 네트워크 대기 시간을 테스트하고 유효성을 검사했습니다. SAP Note 1100926의 네트워크 대기 시간 지침에 따라 결과를 평가합니다. 네트워크 대기 시간이 보통이거나 정상 범위에 있어야 합니다.
필요할 때 적절한 암호화 방법으로 암호화가 구현되었습니다.
자체 암호화 키는 손실, 소멸 또는 악의적인 사용으로부터 보호됩니다.
인터페이스 및 기타 애플리케이션을 새로 배포된 인프라에 연결할 수 있습니다.
SAP 환경에서의 자동화된 검사 및 인사이트
위의 몇 가지 검사는 Azure의 SAP 품질 검사 도구를 사용하여 자동화된 방식으로 확인됩니다. 이러한 검사는 제공된 오픈 소스 프로젝트를 통해 자동화하여 실행할 수 있습니다. 도구가 발견된 문제를 자동으로 수정하진 않지만, Microsoft 권장 사항에 어긋나는 구성을 경고할 것입니다.
더 쉽게 배포 검사 및 결과 기록을 수행하고, 이어지는 수정 단계를 계획하고, Azure의 SAP 환경을 일반적으로 최적화할 수 있는 추가 도구는 다음과 같습니다.
Azure Well-Architected Framework 검토는 안정성, 보안, 비용 최적화, 운영 우수성, 성능 효율성의 5가지 기본 핵심 요소에 집중한 워크로드 평가입니다. SAP 워크로드를 지원하며 모든 프로젝트 단계 시작 및 완료 후에 검토를 실행하는 것이 좋습니다.
SAP용 Azure 인벤토리 검사는 구성 드리프트를 강조 표시하고 품질을 개선하기 위해 인텔리전스가 포함된 Azure 인벤토리를 보여 주는 오픈 소스 Azure Monitor 통합 문서입니다.